Michael Sphers，有效使用遗留代码，第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分钟才能运行。
答案 0 :(得分：23)
我看过一个这样的项目，其中单元测试的数量使得系统花费太长时间来测试所有内容。 “太长”意味着您基本上没有将其作为正常开发程序的一部分。
然而，他们所做的是将单元测试分为两部分。关键测试和“其他一切”。
关键测试只花了几秒钟才运行，并且只测试了系统中最关键的部分，这里的“关键”意味着“如果这里出现问题，一切将会出错”
使整个运行时间过长的测试被降级为“其他所有”部分，并且仅在构建服务器上运行。
每当有人将代码提交到源代码控制存储库时，关键测试将再次运行，然后在未来几分钟内安排“完整运行”。如果在该间隔期间没有人签入代码，则运行完整测试。当然，他们没需要30分钟，更像是8-10分钟。
这是使用TeamCity完成的，因此即使一个构建代理忙于完整的单元测试套件，其他构建代理仍然可以选择正常提交并根据需要运行关键单元测试。
答案 1 :(得分：6)
我只参与了测试套件至少十分钟运行的项目。更大的，更像是小时。我们把它吸了起来等待，因为他们几乎可以保证在你投掷的任何东西中至少找到一个问题。这些项目非常庞大而且毛茸茸。
我想知道这几个项目可以在几秒钟内全面测试。
（当你的项目单元测试花费数小时时完成工作的秘诀就是你要同时处理四到五件事。你在测试套件中抛出一组补丁并进行任务切换，当你完成了切换到的东西时，也许你的结果会回来。）
答案 2 :(得分：3)
首先，请参阅我对Zack关于UNIT测试和INTEGRATION测试之间差异的答案的评论。
接下来，使用像Might-Moose这样的工具（Mighty-Moose被放弃，但还有其他工具），每次签入文件时，只运行受代码更改影响的测试（而不是整个测试库）
答案 3 :(得分：2)
我的单元测试需要几秒钟才能执行。我有一个方法可以进行非常复杂的计算和数十亿次操作。当我们重构这种棘手且超级快速的方法（我们必须优化它的垃圾时，有一些我们用作单元测试基础的好的值，因为正如我所说，它正在进行数十亿甚至数十亿的计算。）
规则不适应每个域/问题空间。
我们不能将这种方法“划分”为我们可以进行单元测试的较小方法：它是一种微小但非常复杂的方法（利用疯狂巨大的预先计算的表格，无法在飞行中快速重新创建等）。
我们对该方法进行了单元测试。它们是单元测试。它们需要几秒钟才能执行。这是一件好事[TM]。
现在我当然不会怀疑您是否使用像JUnit这样的单元测试库来处理非单元测试：例如我们还使用JUnit来测试复杂的多线程场景。这些不是“单元测试”，但你敢打赌，JUnit仍然掌控着这一天：）
答案 4 :(得分：0)
那么你的问题是什么？ :-)我同意，这里的真正指标是开发人员必须等待完整的单元测试运行多长时间。太长了，他们会在提交代码之前开始偷工减料。我希望看到一个完整的提交构建花费不到一两分钟，但这并不总是可行的。在我的工作中，提交构建过去花费了8分钟，人们刚开始只在运行之前运行它的一小部分 - 所以我们购买了更强大的机器： - ）
答案 5 :(得分：0)
开发人员等待单元测试套件完成需要多长时间？ 这真的取决于开发者愿意等待他们的变化反馈多久。我会说，如果你开始谈论会议纪要而不是太慢，你应该把测试套件拆分成单独的测试项目并单独运行。