我们针对单元测试(每秒测试)的目标执行率是什么？单个单元测试需要多长时间？

我想知道人们是否有任何特定的阈值来确定他们的测试是否太慢，还是只是长时间运行的测试套件的摩擦力使我们变得更好？

最后，当我们确定测试需要更快地运行时，我们使用什么技术来加快测试速度？

注意：集成测试显然又是另一回事了。我们严格地讲单元测试需要尽可能频繁地运行。

回应汇总：感谢我们到目前为止的好评。大多数建议似乎都不担心速度-专注于质量，如果速度太慢，则只选择有选择地运行它们。有具体数字的答案包括针对每次测试在10毫秒内以不超过10毫秒的速度达到0.5秒和1秒，或者只是将整套常规测试保持在10秒以内。

当它们都有用时，不确定将其标记为"可接受的答案"是否正确：)

解决方案

回答

我倾向于将重点更多地放在测试的可读性上，而不是速度上。但是，我仍然尝试使它们更快。我认为，如果它们以毫秒为单位运行，那很好。如果他们每次测试运行一秒钟或者更长时间...那么我们可能正在做一些应该优化的事情。

慢速测试仅会随着系统的成熟而成为问题，并导致构建花费数小时，这时我们很可能会遇到很多慢速测试的问题，而不是一两个可以轻松优化的测试。因此，如果我们看到很多测试每次运行数百毫秒(或者更糟糕的是，每个秒)，那么我们可能应该马上注意，而不是等到它花了很长时间才进行数百次测试(此时将要进行)真的很难解决这个问题)。

即使这样，它也只会减少自动构建发出错误之间的时间...我认为，如果过了一个小时(甚至是几个小时)，就可以了。问题是在签入之前运行它们，但是可以通过选择一小部分要运行的与我们正在从事的测试有关的测试来避免这种情况。如果我们签入破坏未运行测试的代码，请确保修复该构建！

回答

如果我们严格讲单元测试，那么我追求的是完整性而不是速度。如果运行时开始引起摩擦，请将测试分为不同的项目/类等，并仅运行与我们正在从事的工作有关的测试。让Integration Server在签入时运行所有测试。

回答

目前，我们在大约3秒钟的时间内进行了270项测试。大约有8个测试可以执行文件IO。

在成功在每台工程师机器上构建我们的库之后，这些文件会自动运行。我们进行了更广泛(且耗时)的烟雾测试，该测试由构建机器每晚进行，或者可以在工程师机器上手动启动。

如我们所见，我们尚未达到测试过于耗时的问题。对我来说10秒钟是开始变得令人厌烦的时刻，当我们开始接近它时，我们将对其进行研究。我们可能会将较低级的库(由于它们不经常更改且几乎没有依赖关系)变得更健壮，将其移入夜间构建或者仅由构建计算机执行的配置中。

如果发现运行一百多个测试需要花费几秒钟的时间，则可能需要检查分类为单元测试的内容以及是否将其更好地视为冒烟测试。

里程显然会随开发领域而变化很大。

回答

我以每个测试为基础来判断我的单元测试，而不是以每秒的测试为依据。我的目标速度是500ms或者更短。如果高于该值，我将调查测试以找出为什么要花这么长时间。

当我认为测试变慢时，通常意味着测试做得太多。因此，仅通过将测试分解为更多测试来重构测试就可以解决问题。我还注意到测试运行缓慢的其他时间是，当测试在我的代码中显示出瓶颈时，就可以对代码进行重构了。

回答

所有单元测试应在一秒钟内运行(也就是说，所有组合单元测试应在一秒钟内运行)。现在，我确定这有实际的限制，但是我有一个包含1000个测试的项目，可以在笔记本电脑上快速运行。我们会真正想要这样的速度，这样开发人员就不会担心重构模型的某些核心部分(即，在我运行这些测试时，Lemme去喝咖啡了……10分钟后他回来了)。

此要求还迫使我们正确设计应用程序。这意味着域模型是纯净的，并且包含对任何类型的持久性(文件I / O，数据库等)的零引用。单元测试都是关于测试那些业务关系的。

现在，这并不意味着我们会忽略测试数据库或者持久性。但是，现在这些问题被隔离在存储库之后，可以使用位于单独项目中的集成测试来单独测试这些存储库。我们在编写域代码时会不断运行单元测试，然后在签入时运行一次集成测试。

回答

UnitTest ++的作者在Power Of Two游戏中有一篇很好的文章。

回答

数据点-Python回归测试

这是笔记本电脑上用于运行Python 2.5.2的"制造测试"的数字：

• 测试次数：3851(大约)
• 执行时间：9分6秒
• 执行速度：7次测试/秒

回答

How long is too long for an individual
  unit test?

我会说这取决于编译速度。通常在每次编译时都要执行测试。单元测试的目的不是要放慢速度，而是要发出"什么都没有破坏，继续下去"(或者"什么东西破坏了，停止")的信息。

在开始变得烦人之前，我不会担心测试的执行速度。

危险是因为测试太慢而停止运行测试。

Finally, when you do decide the tests
  need to run faster, what techniques do
  you use to speed up your tests?

首先要做的是设法找出它们为什么太慢，以及问题出在单元测试还是被测代码中？

我会尝试将测试套件分为几个逻辑部分，只运行应该受到每次编译时更改的代码影响的部分。我运行其他套件的频率较低，也许每天运行一次，或者有疑问的时候我可能已经损坏了某些东西，至少在集成之前。

回答

目标是每秒进行100次测试。遵循迈克尔·费瑟(Michael Feather)的单元测试规则，即可达到目标。

在过去的CITCON讨论中提出的一个重要观点是，如果测试不是那么快，那么很可能没有获得单元测试的设计优势。

回答

一些框架会根据启发式方法(例如上次修改的时间)自动执行特定的单元测试。对于Ruby和Rails，自动测试提供了更快，响应速度更快的测试执行-当我保存Rails模型" app / models / foo.rb"时，将运行" test / unit / foo_test.rb"中的相应单元测试。

我不知道其他平台是否存在类似的东西，但这是有道理的。