如果有一个项目具有作为构建机器上的构建过程的一部分执行的测试，如果一组测试失败，整个构建是否会失败？
回答这个问题时应该考虑什么？这些测试失败了吗？促使这个问题如果失败的测试会使连续构建失败？
背景资料：
目前我的工作有NUnit测试，完成作为构建过程的一部分，我们的cruise control .net构建机器上执行一个项目。
该项目用于设置，以便如果任何测试失败，构建失败。推理是如果测试失败，这意味着产品不能正常工作/不完整/项目失败，因此构建失败。
我们已经添加了一些测试，虽然他们失败了，但他们对项目并不关键（详情见下文）。所以如果这些测试失败了，那么这个项目并不是完全失败，我们仍然希望它能够建立。
其中一个通过的测试验证不正确的参数导致异常，但测试未通过的是检查所有允许的参数是否为而非导致异常的测试。所以班级拒绝所有无效的案件，但也有一些有效的案件。这对于这个项目来说并不是问题，因为被拒绝的有效论据是应用程序不会依赖的边缘案例。
如果它以任何方式可行，那就去做吧。它大大减少了broken-window-problem：
在没有（可见）缺陷的系统中，引入一个小缺陷通常被认为是一个非常糟糕的主意。因此，如果你有一个绿色状态的项目（没有单元测试失败），并且你介绍了第一个失败的测试，那么你（和/或你的同伴）将会被激励来解决这个问题。
如果在另一方面存在已知失败的测试，那么只添加另一个破坏的测试被视为保持现状。
因此，您应该始终努力保持所有测试运行（而不仅仅是“大多数”）。将每一次失败的测试都视为失败的原因，对于实现这一目标有很长的路要走。
如果单元测试失败，某些代码的行为并不像预期的那样。所以代码不应该被释放。
虽然您可以为构建测试/ bug修复目的。
如果您觉得某个案例足够重要，可以编写测试，那么如果该测试失败，则该软件将失败。基于这一点，是的，它应该认为构建失败并且不会继续。如果你不使用这种推理，那么谁来决定哪些测试不重要？ “如果失败就没关系，但如果失败则不是”？失败就是失败。
我认为像你这样的好设置应该总是成功构建，包括所有传递的单元测试。
就像Gamecat说的那样，构建本身是成功的，但是这段代码永远不会投入生产。
想象一下你的团队成员介绍，其中一个单元测试（这总是失败）覆盖代码中的错误之一。它不会被测试发现，因为您允许一个测试总是失败。
在我们的团队，我们有一个简单的策略：如果所有测试没通过，我们不要去生产的代码。对于我们的项目经理来说，这也是一个非常简单的理解。
在我看来，它真的取决于你的单元测试，如果你的单元测试真的是单元测试（就像他们应该=>“参考无尽的书籍）”） 然后构建应该失败，因为某些东西不应该像......
但是大多数情况下（不幸地经常看到），在如此多的项目中，这些单元测试只覆盖了一些“边缘”和/或集成测试，然后构建应该继续 （是的，这是一个主观的答案;）
简而言之： 你知道单元测试很好：失败; 其他：建立在
真正的问题是在你失败的测试。你不应该在可以失败的情况下进行单元测试，因为这是一个边缘情况。确定边缘情况是否重要 - 如果不是，则删除单元测试;如果是，然后修复代码。
就像其他一些暗示的答案一样，当单元测试失败时它绝对是代码味道。如果你住用鼻子闻，那么你就不太可能发现下一个问题
所有的答案都已经很大了，这里是我决定的事情：
让测试（或者如果需要进行分割一个失败的测试）NUnit忽略不重要（我问这个问题后我记得这个功能）。这允许：
我认为这是最好的折衷办法，迫使人们修复试验，但不一定马上（但他们必须捍卫现在不是修复它自己的决定，因为每个人都知道他们做到了）。
我实际做了什么：修复了破损的测试。
+1：“附带案件”不是理由。修复代码或修复测试。 – 2009-01-30 14:09:39