unit-testing - 失败的测试是否应该使持续构建失败？

Question

如果一个项目的测试作为构建过程的一部分在构建机器上执行，如果一组测试失败，整个构建是否应该失败？
回答该问题时应考虑哪些事项？哪些测试失败重要吗？

---

提出这个问题的背景信息:

目前我正在做一个有 NUnit 的项目作为构建过程的一部分完成并在我们的 cruise control .net 上执行的测试构建机器。

该项目曾经被设置为如果任何测试失败，则构建失败。原因是如果测试失败，则意味着产品无法正常工作/未完成/这是一个项目的失败，因此构建应该失败。

我们添加了一些测试，虽然它们失败了，但它们对项目并不重要(详情请见下文)。因此，即使这些测试失败，项目也不是完全失败，我们仍然希望它能够构建。

其中一项测试验证不正确的参数会导致异常，但未通过的测试是检查所有允许的参数不会导致异常的测试。因此该类拒绝所有无效案例，但也拒绝一些有效案例。这对项目来说不是问题，因为被拒绝的有效参数是边缘案例，应用程序不会依赖它们。

Answer 1

如果它在任何方面都是可行的，那就去做吧。它大大减少了 broken-window-problem :

在一个没有(可见)缺陷的系统中，引入一个小缺陷通常被视为一个非常糟糕的主意。因此，如果您的项目处于绿色状态(没有单元测试失败)并且您引入了第一个失败的测试，那么您(和/或您的同事)将有动力去解决问题。

如果在另一方面，存在已知失败的测试，则仅添加另一个失败的测试被视为保持现状。

因此，您应该始终努力保持所有 测试运行(而不仅仅是“大部分”)。将每一个失败的测试都视为构建失败的原因对实现该目标大有帮助。