unit-testing - 单元测试太慢有多慢？

Question

Michael Feathers 在《有效处理遗留代码》一书中，第 13-14 页提到:

A unit test that takes 1/10th of a second to run is a slow unit test... If [unit tests] don't run fast, they aren't unit tests.

我可以理解为什么如果有 30,000 次测试，1/10 秒太慢了，因为它需要将近一个小时才能运行。但是，这是否意味着 1/11 秒更好？不，不是真的(因为它只快了 5 分钟)。因此，严格的快速规则可能并不完美。

因此，当考虑到单元测试太慢时，也许我应该重新表述这个问题。 开发人员等待单元测试套件完成需要多长时间？

举一个测试速度的例子。看看几个 MSTest 单元测试持续时间:

0.2637638 seconds
0.0589954
0.0272193
0.0209824
0.0199389
0.0088322
0.0033815
0.0028137
0.0027601
0.0008775
0.0008171
0.0007351
0.0007147
0.0005898
0.0004937
0.0004624
0.00045
0.0004397
0.0004385
0.0004376
0.0003329

所有 21 个单元测试的平均值为 0.019785 秒。请注意，最慢的测试是由于它使用 Microsoft Moles 来模拟/隔离文件系统。

因此，在此示例中，如果我的单元测试套件增长到 10,000 个测试，则运行可能需要 3 多分钟。

Answer 1

我看过一个这样的项目，其中单元测试的数量使系统花费太长时间来测试所有内容。 “太长”意味着您基本上没有将其作为正常开发程序的一部分。

然而，他们所做的是将单元测试分为两部分。关键测试和“其他一切”。

关键测试只需几秒钟即可运行，并且只测试系统中最关键的部分，这里的“关键”意味着“如果这里出现问题，一切都会出错”。

导致整个运行时间过长的测试被降级到“其他一切”部分，并且只在构建服务器上运行。

每当有人将代码提交到源代码控制存储库时，关键测试将再次首先运行，然后在几分钟后安排“完整运行”。如果在这段时间内没有人检查代码，则运行完整的测试。当然，他们没有花 30 分钟，更像是 8-10。

这是使用 TeamCity 完成的，因此即使一个构建代理忙于完整的单元测试套件，其他构建代理仍然可以获取正常提交并根据需要经常运行关键单元测试。