我目前正在为旧版应用程序构建 CI 构建脚本。有零星的 JUnit 测试可用，我会将所有测试的 JUnit 执行集成到 CI 构建中。但是，我想知道如何处理我在非维护 JUnit 测试中遇到的 100 次失败。我：
1) 将它们注释掉，因为它们似乎有合理的业务逻辑，如果没有维护，希望有人最终取消它们并修复它们
2) 删除它们，因为任何人都不太可能修复它们，并且注释掉的代码只会被忽略或永远混乱
3) 追踪那些把这个烂摊子留在我手中的人，并用代码的打印输出敲他们的头（由于长方法的气味将非常适合这项任务），同时宣扬 a 的好处维护良好且经过单元测试的代码库
【问题讨论】：
标签： java junit continuous-integration legacy
如果您使用 Junit 4，您可以使用 @Ignore annotation 注释该测试。
如果您使用 JUnit 3，您可以重命名测试，这样它们就不会以 test 开头。
此外，请尝试修复您正在修改的功能的测试，以免使代码变得更大。
【讨论】：
遵循no broken window 原则并采取一些措施解决问题。如果您无法修复测试，至少：
那么为了防止以后再发生这种情况，安装一个类似于Hudson Game Plugin的插件。人们在持续集成期间获得分配点，例如
非常酷的工具，可以在团队中创建关于单元测试的责任感。
【讨论】：
失败的 JUnit 测试表明
无论哪种方式，您都需要修复/审查测试/源代码。因为听起来你的工作是创建 CI 系统而不是修复测试，所以在你的位置上，我会在测试中留下一颗定时炸弹。您可以使用 JUnit 4（类似于 @IgnoreUntil(date="2010/09/16")）和自定义运行器的带注释的方法非常喜欢，因此或者您可以简单地在每个测试的第一行添加一个 if 语句：
if (isBeforeTimeBomb()) {
return;
}
isBeforeTimeBomb() 可以简单地检查当前日期与您选择的未来日期。然后您按照此处其他人的建议通知您的开发团队该构建现在是绿色的，但很可能在 X 天内爆炸，除非定时炸弹测试得到修复。
【讨论】：
【讨论】：
如果它们编译但失败：将它们留在里面。这将使您在使用 CI 时获得随着时间的推移测试改进的良好历史。如果测试没有编译但破坏了构建，请将它们注释掉并让开发人员修复它们。
这显然不排除使用选项 3（击中他们的头），无论如何你都应该这样做，不管你对测试做什么。
【讨论】：
您现在绝对应该以某种方式禁用它们。无论是通过评论、删除（假设您可以从源代码管理中取回它们）还是其他方式来完成，都取决于您。您不希望这些失败的测试成为尝试提交新更改的人们的障碍。
如果您觉得可以自己修复它们的数量足够少，那就太好了 - 去做吧。如果它们太多，那么我倾向于使用“众包”方法。为每个失败的测试提交一个错误。如果可能，尝试将这些错误分配给测试/测试代码的实际所有者/作者，但如果这太难确定，那么只要您告诉人们重新分配错误分配给他们的错误，随机选择就可以了。然后鼓励人们修复这些错误，方法是给他们一个截止日期或定期通知每个人进度并鼓励他们修复所有错误。
【讨论】：
稳定红色的 CI 系统是毫无价值的。主要好处是保持质量标准，如果没有过渡来标记质量下降，这将变得更加困难。
因此，当务之急应该是禁用失败的测试，并为每个测试创建一个跟踪票/工作项。无论您如何进行分类，这些问题中的每一个都已解决 - 如果没有人关心测试，请摆脱它。如果故障代表需要在发货前解决的问题，则禁用测试。
一旦您处于这种状态，您现在可以依靠 CI 系统告诉您需要采取紧急行动 - 回滚最后的更改，或立即派团队解决问题，或其他任何方式。
【讨论】：
我不知道您在公司的职位，但如果可能的话，请留下他们，并将问题作为错误记录在您的票务系统中。让开发人员自行修复或删除测试。
如果这不起作用，请删除它们（您有版本控制，对吗？）并关闭票证，并使用诸如“删除了显然无法修复的失败的 junit 测试”之类的评论或更礼貌的内容。
关键是，junit 测试是应用程序代码，因此应该可以工作。这就是开发人员获得报酬的原因。如果测试不再合适（不再存在的东西经过测试），开发人员应该发出信号并删除测试。
【讨论】：