测试工程师如何能够在持续集成中协助测试驱动的开发？

Question

在无法合并失败测试的代码的环境中，显然不能合并新的、失败的测试。

但是，如何处理新发现的bug漏洞，这意味着您编写了一个新的测试，公开了一个已经存在的bug。测试驱动开发会说:万岁，您有测试，现在修复错误，然后提交两者。

但是，如果你( a)是一个测试工程师，谁发现了漏洞，但无法修复它，或( b)你将能够修复它，但不是现在？

选项一:将测试提交到一个额外的分支，在bug问题中提到它，并且本质上保留代码直到有人有怜悯之心，并将他们的修复建立在这个分支之上，并同时提交这两个分支。

选项二:在某种程度上将测试标记为“不太好，因为它失败了，但它是预期的”，合并它，而持续集成让它陷入低谷。一旦错误被修复，您就结束了测试的特殊处理，并将其标记为强制性的。也许，CI甚至会显示预期的故障列表，这样您就有了一种额外的bug跟踪器。

是否有任何共同的做法/标准？特别是对于选项二，做标准的测试框架，比如JUnit，Google，.有什么方法来模拟它吗？

Answer 1

永远不要破坏建筑。但是，将来应该通过的测试是完全有效的。许多测试运行程序都理解这种情况下的“xfail”、“未决”或“todo”类别。如果其中一个测试(意外地)开始通过，您可以删除此类别。通过合并这些todo测试，您可以确保它们继续编译和运行，这可能比单独存储这些测试更可取。

示例：

• 在JUnit中，您可以使用注释来标记挂起的测试，尽管您可能需要一个单独的库。仅仅忽略测试可能是不够的，因为不会尝试测试。
• Google可以将测试标记为禁用，并可以执行这些测试，但将失败解释为失败而不是挂起。有了足够的宏，您可以使用自己的解决方案。
• 在Cucumber这样的BDD工具中，挂起的状态是完全正常的。
• Pytest对xfail类别有很好的支持。
• Perl的测试：：更多有TODO块。

是否使用这种方法在很大程度上取决于您团队的工作流程。当您正在实现规范或处理积压的用户故事时，Todo测试是很棒的--特别是在BDD上下文中，测试是规范。如果测试是有价值的文档，那么todo测试对于非常重要的问题也是很好的。

但是对于正常的测试，最好不要陷入大量失败的测试套件中。在编写问题或错误报告时，考虑将测试代码包含在该问题中，而不是合并它。编写一个好的测试已经是调试和解决问题的很大一部分，所以理想情况下，问题可以快速解决。

Answer 2

选项一。仅仅因为你不能合并代码并不意味着你不能签入。您只需要为失败的测试创建一个分支，然后当有人开始处理它时，它就准备好了。

话虽如此，这不是由我们来决定的。这是你的团队需要自己决定的事情。没有任何神奇的子弹，你可以采用，以使这种情况更容易。做对你的团队和你的工作方式最有效的事情。