单元测试执行速度（每秒多少次测试？）

Question

您的单元测试（每秒测试次数）的目标是什么样的执行率？单个单元测试需要多长时间？

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

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

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

---

回复综述：感谢目前为止的回复。大多数建议似乎都不用担心速度 - 专注于质量，如果速度太慢就选择性地运行它们。具有特定数字的答案包括每次测试的目标是<10ms至0.5和1秒，或者仅将整套常用测试保持在10秒以内。

当他们全部帮助时，不确定将一个标记为“已接受的答案”是否正确：）

Answer 1

所有单元测试应在不到一秒的时间内运行（即所有单元测试组合应在1秒内运行）。现在我确定这有实际的限制，但我有一个项目有1000个测试，可以在笔记本电脑上快速运行。你真的想要这个速度，所以你的开发人员不要害怕重构模型的一些核心部分（即，当我运行这些测试时，Lemme去喝咖啡...... 10分钟后他回来了）。

此要求也会强制您正确设计应用程序。这意味着您的域模型是纯粹的，并且包含对任何类型的持久性（文件I / O，数据库等）的零引用。单元测试都是关于测试这些业务关系的。

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

Answer 2

如果我们严格谈论单元测试，我的目标更多是完整而不是速度。如果运行时间开始引起摩擦，则将测试分成不同的项目/类等，并且仅运行与您正在处理的相关的测试。让Integration服务器在checkin上运行所有测试。

Answer 3

目标是每秒100次测试。你到达那里的方式是跟随Michael Feather的rules of unit tests。

过去CITCON讨论中提到的一个重点是，如果您的测试速度不快，很可能您无法获得单元测试的设计优势。

Answer 4

我更倾向于关注测试的可读性而不是速度。但是，我仍然试图让它们相当快。我想如果它们按毫秒级运行，那你很好。如果他们每次测试运行第二次或更多次......那么你可能正在做一些应该优化的事情。

慢速测试只会成为一个问题，因为系统成熟并导致构建需要数小时，此时您更有可能遇到很多慢速测试的问题而不是一两个可以优化的测试很容易...因此，如果你看到很多测试每次运行数百毫秒（或者更糟，每秒几秒），你应该注意正确，而不是等到达到数百个测试时间长点（此时解决这个问题真的很难。）

即便如此，它只会减少自动构建发生错误之间的时间......如果是一小时后（甚至几小时后），这是可以的，我认为。问题是在您签入之前运行它们，但是可以通过选择要运行的与您正在处理的内容相关的一小部分测试来避免这种情况。如果您签入破坏未运行的测试的代码，请确保修复构建！

Answer 5

我们目前正在进行270次测试，时间大约为3.秒。可能有大约8个测试执行文件IO。

这些是在每个工程师机器上成功构建我们的库后自动运行的。我们每天晚上都会通过构建机器进行更广泛（且耗时）的烟雾测试，或者可以在工程师机器上手动启动。

正如您所看到的，我们还没有达到测试过于耗时的问题。对我来说，10秒就是它开始变得侵入的点，当我们开始接近它时，我们将会看到它。我们可能会将较低级别的库移动到夜间构建中，或者只是由构建机器执行的配置，因为它们不经常更改并且具有很少的依赖性，因此它们更加健壮。

如果您发现需要花费几秒钟的时间来进行大约一百次测试，您可能需要检查一下您所分类的单元测试以及是否更好地将其视为烟雾测试。

根据您的发展领域，您的里程显然会变化很大。

Answer 6

数据点 - Python回归测试

以下是我的笔记本电脑上为Python 2.5.2运行“make test”的数字：

• 测试次数：3851（约）
• 执行时间：9分钟，6秒
• 执行率：7次/秒

Answer 7

我在每个测试的基础上判断我的单元测试，而不是每秒测试次数。我的目标是500毫秒或更短。如果高于这一点，我会调查测试，找出为什么这么长时间。

当我认为测试速度缓慢时，通常意味着它做得太多了。因此，只需通过将测试分解为更多测试来重构测试通常就可以了。其他时候我注意到我的测试运行缓慢是当测试显示我的代码中的瓶颈时，然后重新编写代码。

Answer 8

来自Power Of Two游戏的good article是UnitTest++的作者。

Answer 9

  

个人需要多长时间   单元测试？

我会说这取决于编译速度。通常在每次编译时执行测试。单元测试的目标不是放慢速度，而是要发出消息“没有任何损坏，继续”（或“某些东西坏了，停止”）。

我不打扰测试执行速度，直到这开始变得烦人。

危险是停止运行测试，因为它们太慢了。

  

最后，当你确定测试时   需要运行得更快，技术有哪些   你用来加快测试速度吗？

要做的第一件事是设法找出它们为什么太慢，而问题出在单元测试或被测试的代码中？

我试图将测试套件分成几个逻辑部分，只运行所谓的部分，这些部分受到我在每次编译时更改的代码的影响。我不太经常运行其他套房，也许每天运行一次，或者当有疑问时我可能会破坏某些东西，至少在整合之前。

Answer 10

某些框架提供基于启发式（例如上次修改时间）的特定单元测试的自动执行。对于Ruby和Rails，AutoTest提供了更快，响应更快的测试执行 - 当我保存Rails模型app/models/foo.rb时，test/unit/foo_test.rb中相应的单元测试运行。

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

Answer 11

有关单元测试的最重要规则之一是它们应该 快速 。

  

单个单元测试需要多长时间？

开发人员应该能够在几秒钟内运行整套单元测试，绝对不会在几分钟和几分钟内完成。无论如何，开发人员应该能够在更改代码后快速运行它们。如果花费的时间太长，他们就不会打扰它们，你会失去测试的主要好处之一。

  

您的单元测试（每秒测试次数）的目标是什么样的执行率？

你应该瞄准每个测试以毫秒的顺序运行，任何超过1秒的测试都可能测试得太多。

我们目前有大约800次测试，在30秒内完成，每秒约27次测试。这包括启动运行它们所需的移动模拟器的时间。他们中的大多数都需要0-5ms（如果我没记错的话）。

我们有一两个大约需要3秒，这可能是检查的候选对象，但重要的是整个测试套件不会花费太长时间以至于它会让开发人员无法运行它，并且不会显着减慢我们的持续集成构建。

我们还将可配置的超时限制设置为5秒 - 任何花费更长时间的操作都将失败。