替代“通过/损坏的构建”指示器？

Question

当连续集成在每次提交时执行测试时，一个常见的最佳实践是让所有测试在任何时候都通过(也就是“不要破坏构建”)。

我发现有一些问题：

例如，不能通过创建与票证相对应的测试来帮助开源项目。我知道，如果我向包含失败测试的开源项目提出拉请求，构建将被标记为失败，并且该项目不希望将其合并到其存储库中，因为它将“破坏构建”。

我不认为在你的回购中测试不及格是件坏事，就像你的追踪器中有未解决的问题一样。这些只是等待修复的东西。

在公司里也是如此。如果使用TDD，则无法编写测试、提交并编写完成测试的逻辑代码。这意味着如果我在笔记本电脑上写了4-5的测试，我就不能在假期前提交它们。没人能收回我的作品。我甚至不能与同事“分享”，除非通过电子邮件发送。它还防止一个人编写测试，另一个人编写模型。

所有这些都是在说，我是否误用/误解了构建过程/持续集成？在我看来，“通过”/“不通过”是一个过于狭窄的指标。

是否有办法使持续集成和TDD兼容？

也许有一种标准的解决方案/实践来区分“新测试”(可能失败)和“回归测试”(不应该失败，因为它们曾经有效)？

Answer 1

我知道你在做什么，但这些类型的问题通常都是通过其他方式解决的。有一个很好的理由来解释为什么这是标准协议。如果有人提交了没有编译的代码，那么更新他/她的代码的每个人都会有一个不编译的程序。这包括目前正在从事完全不同的工作的程序员，他们发现自己处于一种需要等待的情况下，然后才能编译和测试他们正在做的工作。

标准协议是，您可以提交更改，即使是完成或甚至不完整的工作，只要它编译，以便程序员可以每天更新他们的代码，如果必要的话。

不过，我还是明白你在说什么。有时，为了简单地保存代码，您想要提交。为此，大多数源存储库都支持分支。这允许您创建一个私有分支，在不打扰其他人的情况下处理它，然后在工作完成后合并到主干中。这允许您在不需要任何与导致构建中断相关的反弹的情况下提交。

如果这样做不合适，GIT允许您提交(推送)到本地机器上的存储库，但可以想象存储库可能在任何地方。您可以为可能部分/不完整的工作创建一个存储库，为已完成的工作创建另一个存储库，并且可以在该存储库上添加一个夜间构建。

再说一次，我怎么强调都不够。永远不要将中断的代码提交到主干！您的贡献不能影响其他程序员的工作。

编辑

我知道你打算考试失败，但在我看来，没有什么区别。测试的全部目的是确定程序的一个特定方面是否通过或失败。如果它总是失败而您什么也不做，那么在传统的单元测试的使用中，测试就没有任何作用。如果您使用它来执行其他度量，如果其中一个测试失败，则不一定需要“失败”提交，那么我强烈建议您找到另一种方法来做同样的事情。

否则，您将面临这样的风险:测试从来没有被考虑过，或者如果它导致您的构建失败，那么您的程序员就会忽略失败的构建。更重要的是，程序员意识到，当他们破坏了一个构建，而不是执行一个测试，没有提供真正的洞察力，可能只会导致错误的做法。

Answer 2

给定测试失败的主分支，您如何确保--不将该列表与以前的构建进行比较--您没有引入bug？

仅仅跟踪失败测试的数量是不够的:您可能修复一个测试，而破坏另一个测试。如果你在度假，对其他人来说，看失败的构建是不清楚的。

在任何时候都要保持主树枝的清洁和绿色。在一个分支机构工作。保持分行的CI，在一个单独的工作，并有失败的测试，以您的心的满足。别打断主人。

只有在分支通过所有测试时，分支的审阅者才会合并您的分支。(更强烈的是:只有当将分支合并为主版的结果通过所有测试时，评审方才能合并您的分支！)

Answer 3

有一些方法可以解决您的问题，而不抛弃对持续集成的理解和接受的实践。

我将从提交一个与罚单相对应的“坏测试”开始。一种解决方案是创建一个或多个暴露问题的中断测试，然后实际修复问题，以便将它们合并回主代码行。第二个解决方案是有坏的测试，但是使用某种类型的忽略标志，这样它们就不会实际运行并破坏构建。可能会添加注释或特殊注释，从而非常明显地表明这是对Ticket#N的一个失败的测试。另外，在票据本身上附加一个注释，它引用正在等待被unignored和运行的创建的测试。这将有助于一个人的罚单，但也不会是一个危险的人谁通过测试。

下一个关于TDD的问题。TDD是关于编写一个小测试，然后编写一小块代码来通过测试。然后继续迭代，直到您有了一个小的功能模块。我觉得如果你写了4-5的测试，然后你去度假，你可能做错了。您可以将程序与某人配对，以一种方式编写测试，另一种方式编写相应的代码。但是，在准备提交一个完整的模块之前，您不应该使用主代码行存储库在两个人之间共享这段代码。正如其他人所建议的，一个共享的分支可以解决您在那里的问题。

试图打破持续集成的咒语可能会导致意想不到的和可怕的路径。例如，在这种环境中，代码覆盖率意味着什么？开发人员怎么会不觉得系统有很多“破窗”呢？一个人如何做出改变，运行测试，并知道他们到底是在打破任何新的东西，还是仅仅是旧的东西？