迈克尔·费瑟斯有效地处理遗留代码，第 13-14 页提到：
单元测试需要 1/10
第二个运行是一个缓慢的单元测试......
如果[单元测试]运行得不快，他们
不是单元测试。
我可以理解为什么如果有 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 个测试，could运行时间超过3分钟。
我研究过一个这样的项目，其中单元测试的数量使得系统需要很长时间才能测试所有内容。 “太长”意味着您基本上没有将其作为正常开发例程的一部分。
然而，他们所做的是将单元测试分为两部分。关键测试和“其他一切”。
关键测试只需要几秒钟就可以运行，并且只测试系统最关键的部分，这里的“关键”意味着“如果这里出现问题，一切将会出错”。
导致整个运行时间过长的测试被归入“其他所有”部分，并且仅在构建服务器上运行。
每当有人将代码提交到源代码控制存储库时，关键测试将再次首先运行，然后在未来几分钟内安排“完整运行”。如果在该时间间隔内没有人签入代码，则会运行完整的测试。当然，他们用的时间不是 30 分钟，而是 8-10 分钟。
这是使用 TeamCity 完成的，因此即使一个构建代理忙于完整的单元测试套件，其他构建代理仍然可以获取正常提交并根据需要经常运行关键单元测试。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
