Mat*_*att 27 performance unit-testing mstest
迈克尔·费瑟斯(Michael Feathers)在第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个测试,则运行可能需要3分钟.
ang*_*son 23
我看过一个这样的项目,其中单元测试的数量使得系统花费太长时间来测试一切."太长"意味着您基本上没有将其作为正常开发程序的一部分.
但是,他们所做的是将单元测试分为两部分.关键测试和"其他一切".
关键测试只需几秒钟就可以运行,只测试系统中最关键的部分,这里的"关键"意味着"如果这里出现问题,一切都会出错".
使整个运行时间过长的测试被降级为"其他所有"部分,并且仅在构建服务器上运行.
每当有人将代码提交到源代码控制存储库时,关键测试将再次运行,然后在未来几分钟内安排"完整运行".如果在该间隔期间没有人签入代码,则运行完整测试.当然,他们没需要30分钟,更像是8-10分钟.
这是使用TeamCity完成的,因此即使一个构建代理忙于完整的单元测试套件,其他构建代理仍然可以获取正常提交并根据需要经常运行关键单元测试.
我只参与了测试套件运行至少十分钟的项目.更大的,更像是小时.我们把它吸了起来等待,因为他们几乎可以保证在你投掷的任何东西中至少找到一个问题.这些项目非常庞大而且多毛.
我想知道这些项目可以在几秒钟内全面测试.
(当项目的单元测试需要几个小时时,完成任务的秘诀就是要同时处理四到五件事.你在测试套件中抛出一组补丁,然后进行任务切换,并通过你完成了切换到的东西的时间,也许你的结果已经回来了.)