如果一个项目的测试作为构建计算机上构建过程的一部分执行，那么如果一组测试失败，整个构建是否应该失败？
回答这个问题时应该考虑哪些因素？哪些测试失败重要吗？
提出这个问题的背景信息：
目前我正在开发一个项目NUnit http://www.nunit.org/作为构建过程的一部分完成的测试，并在我们的巡航控制.net http://ccnet.thoughtworks.com/构建机器。
该项目过去的设置是，如果任何测试失败，构建就会失败。原因是如果测试失败，则意味着产品无法工作/不完整/项目失败，因此构建应该失败。
我们添加了一些测试，尽管它们失败了，但它们对项目并不重要（更多详细信息请参见下文）。因此，如果这些测试失败，该项目并不是完全失败，我们仍然希望它能够构建。
通过的测试之一验证不正确的参数是否会导致异常，但未通过的测试是检查所有允许的参数是否正确not导致异常。因此该类拒绝所有无效的情况，但也拒绝一些有效的情况。这对于项目来说不是问题，因为被拒绝的有效参数是边缘案例，应用程序不会依赖这些案例。
如果它以任何方式可行，那就去做吧。它大大减少了破窗问题 http://www.pragprog.com/the-pragmatic-programmer/extracts/software-entropy:
在没有（可见）缺陷的系统中，引入一个小缺陷通常被视为一个非常糟糕的主意。因此，如果您有一个处于绿色状态的项目（没有单元测试失败）并且您引入了第一个失败的测试，那么您（和/或您的同事）将有动力去解决问题。
另一方面，如果存在已知的失败测试，则添加另一个失败的测试将被视为保持现状。
因此你应该始终努力保持all测试正在运行（而不仅仅是“大多数”）。将每一个失败的测试都视为构建失败的原因对于实现这一目标大有帮助。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
