整个系统单元测试套件应该多久运行一次？答案

【问题标题】：how often should the entire suite of a system's unit tests be run?整个系统单元测试套件应该多久运行一次？
【发布时间】：2011-02-22 08:50:22
【问题描述】：

一般来说，我仍然是一个单元测试新手。

顺便说一句，您也可能在 xUnit.net 等其他论坛上看到此问题，
因为这对我来说是一个重要的问题。我提前为我的
交叉张贴；您的意见对我很重要，而不是每个人
在这个论坛也属于其他论坛。

我正在查看一个拥有 700 多个单元测试的大型旧系统
最近写的（700只是一个小小的开始）。测试碰巧写好了
在 MSTest 但这个问题适用于所有测试框架 AFAIK。

当我通过 vs2008 "ALL TESTS" 运行时，最终计数只有七个测试。
这大约是迄今为止编写的测试总数的 1%。

更多信息：ASP.NET MVC 2 RTM 源代码，包括其单元测试，
在 CodePlex 上可用；这些单元测试也是用 MSTest 编写的
尽管（无关的事实）Brad Wilson 后来加入了 ASP.NET MVC 团队
作为它的高级程序员。所有 2000 多个测试都会运行，而不仅仅是少数几个。

问题：鉴于 AFAIK，单元测试的目的是识别破损
在 SUT 中，我认为“最佳实践”始终是正确的，
或者至少非常频繁地运行所有测试？

2010 年 5 月 22 日更新

首先，感谢所有提供出色答案的人。你的答案确认我的一般结论，即在每次本地重建后运行所有单元测试是最佳实践，无论是在练习 TDD（之前测试）还是经典单元测试（测试后）。

恕我直言，这个问题有不止一个最佳答案，但 AFAIK SO 让我只选择一个，所以为了公平起见，我打了勾皮特·约翰斯（Pete Johns）获得第一名并获得 SO 的最高票数社区。芬兰的 Esko Luontola 也给出了很好的回答（希望他没有被火山灰掩埋）和两个非常好的链接值得你花时间恕我直言；绝对是 F.I.R.S.T. 的链接。对我来说是鼓舞人心的； AFAIK，.NET 世界中只有 xUnit.net 提供“任何订单，任何时间”。 Esko 的第二个链接是一个真正出色的 92 分钟视频“集成测试是骗局” 由 J. B. (Joe) Rainsberger (http://jbrains.ca 提供更多内容值得我花时间）。顺便说一句，Esko 的博客也值得一游 http://orfjackal.net。

【问题讨论】：

700 个单元测试对于遗留系统来说是个好消息！保持势头！

标签： unit-testing tdd nunit mstest xunit.net

【解决方案1】：

最佳实践当然是在签入时或签入之前运行单元测试。当然，单元测试有可能在签入之前在机器上通过，但是当实际代码库的一部分其他更新合谋破坏单元测试，所以它们也应该在完整的代码上运行。

有一些工具可以帮助您解决这个问题，例如 TeamCity，它允许您有条件地签入，在签入之前它会在其中为您运行测试，并在每次检查后运行构建，包括测试（如果已配置）（这种做法称为持续集成）。

无论最佳实践如何，现实情况是，如果您运行测试太晚，则更难追踪失败的原因，并且随着时间的推移，失败的测试将被注释掉，甚至允许更糟糕的测试保持失败状态，导致新的失败测试被忽视。

【讨论】：

【解决方案2】：

应该可以快速运行单元测试，这样您就可以在每次简单更改后运行它们。正如http://agileinaflash.blogspot.com/2009/02/first.html 所说的

测试必须很快。如果您在简单的单行更改后犹豫是否运行测试，那么您的测试太慢了。使测试如此之快，您不必考虑它们。 [...] 一个软件项目最终会有数以万计的单元测试，并且团队成员需要每分钟左右都运行它们而不感到内疚。你自己算算。

就我个人而言，我的疼痛阈值约为 5-10 秒；如果编译和运行所有单元测试的时间比这更长，那会很烦人并拖慢我的速度。

如果有慢速集成测试 (which should be avoided)，它们可以在每次签入时运行。最好由开发人员在他签入之前，然后再次在持续集成服务器上。

【讨论】：

即使是集成测试也应该很快。
@Gutzofter - 在理想情况下，集成测试应该很快。但是集成测试经常会遇到我们开发人员无法控制的真实世界资源，例如数据库或自定义硬件。它们可能不会很快。
引用和 4 5-10 秒个人阈值 +1。

【解决方案3】：

由于您已将此问题标记为“TDD”，因此应在每次编译时执行正在开发的模块的所有单元测试（并通过，除非最新的测试通过，直到您通过）。其他模块中的单元测试不应因当前模块中的开发而中断，否则它们测试过多。

还应该建立一个持续集成循环，以确保所有测试在每次签入源代码控制系统时运行。这将尽早捕获破损。

至少，每晚的构建都应该运行每一个测试，并且在早上的第一件事就是修复任何损坏。不允许任何单元测试失败！

【讨论】：

+1 用于为正在开发的模块运行所有测试。我会提到 TDD 实践者的口头禅：RED-GREEN-REFACTOR。红色是失败的测试。 Green 从编写使测试通过所需的最少代码开始，并且还确保您没有破坏任何其他测试。为了确保这一点，您必须为正在开发的模块运行所有测试。在这种模式中，您总是在编写使测试通过的最少量代码之后运行所有测试（针对正在开发的模块）。正如@Esko Luontola 所说，要实现这一点，所有测试必须在 5-10 秒内运行。

【解决方案4】：

理想情况下，单元测试应作为每次构建的一部分并在每次签入更改的代码之前运行。

但是，由于需要进行大量测试，这可能需要很长时间，因此您需要能够管理好它。

仅运行测试的一个子集可能如果子集被轮换并且整套测试每周运行一次（例如）就足够了，但这仍然为在测试中留下重大更改留下了时间几天的代码库。

您必须在签入之前运行所有测试，因为您无法知道您的更改没有对代码的其他部分产生不利影响。我一次又一次地看到这种情况，如果没有单元测试，它非常很难发现。

【讨论】：

【解决方案5】：

由于单元测试可以自动化，我建议尽可能频繁地运行它们，尤其是当你有这么多的时候。

最佳实践是将单元测试作为夜间构建过程的一部分运行。

【讨论】：