替代“通过/损坏的构建”指示器？
当在每次提交时执行测试的持续集成时，通常的最佳实践是使所有测试始终通过（也就是“不破坏构建”）。 我发现一些问题： 例如，不能通过创建与票证相对应的测试来帮助开源项目。我知道如果我向包含失败测试的开源项目提出“拉取请求”，则该构建将被标记为失败，并且该项目将不希望将其合并到其存储库中，因为这会“破坏构建”。 而且我不认为在您的仓库中测试失败是一件坏事，就像在跟踪器中遇到未解决的问题一样。这些只是等待修复的事情。 公司也是如此。如果使用TDD，则无法编写测试，提交并编写满足测试要求的逻辑代码。这意味着，如果我在笔记本电脑上编写了4-5个测试，则在休假前我无法提交它们。没有人可以收回我的工作。我什至不能与同事“共享”他们，例如通过电子邮件发送给他们。这也阻止了一个人编写测试，而另一个人编写模型。 话虽如此，我是否滥用/误解了构建过程/持续集成？在我看来，“通过” /“未通过”是一个过于狭窄的指标。 有没有办法使持续集成和TDD兼容？ 也许有一个标准的解决方案/实践来区分“新测试”（可能失败）和“回归测试”（应该不会失败，因为它们曾经工作过）？