如果某个项目的某个项目具有在构建计算机上作为构建过程的一部分执行的测试，那么如果集合测试失败，那么整个构建是否会失败？ 回答这个问题时应该考虑哪些事项？哪些测试失败是否重要？
提示此问题的背景信息：
目前我正在开发一个项目，该项目具有NUnit个测试，这些测试是作为构建过程的一部分完成的，并在我们的cruise control .net构建机器上执行。
以前设置项目，以便在任何测试失败时，构建失败。原因是如果测试失败，这意味着产品不工作/不完整/它是项目的失败，因此构建应该失败。
我们已经添加了一些测试，尽管它们失败了，但它们对项目并不重要（详见下文）。因此，如果这些测试失败，那么项目就不会完全失败，我们仍然希望它能够构建。
其中一个测试通过验证不正确的参数会导致异常，但测试未通过的是检查所有允许的参数不导致异常的测试。因此，班级拒绝所有无效案件，但也拒绝一些有效案件。这对项目来说不是问题，因为被拒绝的有效参数是边缘情况，应用程序不会依赖它。
答案 0 :(得分：15)
如果它以任何方式可行，那就去做吧。它大大减少了broken-window-problem：
在没有（可见）缺陷的系统中，引入一个小缺陷通常被视为一个非常糟糕的主意。因此，如果您有一个绿色状态的项目（没有单元测试失败）并且您引入了第一个失败的测试，那么您（和/或您的同行）将有动力解决问题。
另一方面，如果有已知的失败测试，那么只添加另一个破坏的测试就会被视为保持现状。
因此，您应始终努力使所有测试运行（而不仅仅是“大部分”）。并且将每一次失败的测试都视为构建失败的原因，这对于实现这一目标还有很长的路要走。
答案 1 :(得分：4)
如果单元测试失败，则某些代码的行为不符合预期。因此代码不应该被释放。
虽然您可以构建用于测试/修复错误的目的。
答案 2 :(得分：2)
如果你觉得一个案例对于编写测试非常重要，那么如果该测试失败，那么软件就会失败。仅基于此，是的，它应该认为构建失败而不是继续。如果你不使用这种推理，那么谁决定哪些测试不重要？ “如果失败就可以了，但如果失败就不行”之间的界限在哪里？失败就是失败。
答案 3 :(得分：1)
我认为像你这样的好设置应该总是成功构建，包括所有通过的单元测试。
就像Gamecat所说，构建本身是成功的，但是这段代码永远不会投入生产。
想象一下，您的团队成员之一在代码中引入了一个单元测试（总是失败）的错误。测试不会发现它，因为您允许一个测试始终失败。
在我们的团队中，我们有一个简单的策略：如果所有测试都没有通过，我们不会使用代码进行生产。对于我们的项目经理来说，这也很容易理解。
答案 4 :(得分：0)
在我看来，这取决于你的单元测试，...... 如果你的单元测试真的是单元测试（就像它们应该是=＆gt;“参考无尽的书籍;）”） 然后构建应该失败，因为某些东西的行为不应该......
但最常见的（不幸的是经常看到），在这么多项目中，这些单元测试只涵盖了一些“边缘”和/或是集成测试，然后构建应该继续 （是的，这是一个主观的答案;）
简而言之： 你知道单元测试没问题吗：失败; 否则：建立在
上答案 5 :(得分：0)
真正的问题在于您的测试失败。你不应该在可以失败的情况下进行单元测试，因为它是一个边缘情况。确定边缘情况是否重要 - 如果不重要则删除单元测试;如果是，则修复代码。
就像隐含的其他一些答案一样，当单元测试失败时，它肯定是代码味道。如果你忍受了气味，那么你就不太可能发现下一个问题
答案 6 :(得分：0)
所有答案都很棒，这就是我决定做的事情：
让NUnit忽略不重要的测试（或者如果需要拆分一个失败的测试）（在提出问题后我记得这个功能）。这允许：
我认为这是最好的妥协，迫使人们修理测试，但不一定马上（但是他们必须捍卫他们现在不修理它的决定，因为每个人都知道他们做了什么）。
我实际做了什么：修复了破损的测试。