删除或注释掉非工作的JUnit测试？

Question

我目前正在为遗留应用程序构建CI构建脚本。有可用的零星JUnit测试，我将把所有测试的JUnit执行集成到CI构建中。但是，我想知道如何处理我在非维护的JUnit测试中遇到的100'失败。我：

1）评论它们，因为它们似乎具有合理的，如果没有维护的业务逻辑，希望有人最终取消注释并修复它们

2）删除它们，因为不太可能有人会修复它们，注释掉的代码只会被忽略或者变得混乱

3）追踪那些把这个烂摊子留在我手中并用打印机代码打印头部的人（由于长方法气味将足以适合任务），同时宣扬一个好处维护良好且经过单元测试的代码库

Answer 1

如果您使用Junit 4，则可以使用@Ignore annotation注释该测试。

如果你使用JUnit 3，你可以重命名测试，使它们不以test开头。

此外，尝试修复您正在修改的功能的测试，以免使代码变得更大。

Answer 2

失败的JUnit测试表明

1. 正在测试的源代码已经过处理而没有维护测试。在这种情况下，选项3绝对值得考虑，或
2. 你真的失败了。

无论哪种方式，您都需要修复/查看测试/来源。因为听起来你的工作是创建CI系统而不是修复测试，所以在你的位置我会在测试中留下定时炸弹。使用带有JUnit 4（类似@IgnoreUntil(date="2010/09/16")）和自定义运行器的带注释方法，你可以非常喜欢这样，或者你可以简单地在每个测试的第一行添加一个if语句：

  if (isBeforeTimeBomb()) {
    return;
  }

isBeforeTimeBomb()可以根据您选择的未来日期查看当前日期。然后，您按照其他人给出的建议，通知您的开发团队现在构建为绿色，但是在X天内可能会爆炸，除非时间戳测试得到修复。

Answer 3

遵循no broken window原则并采取一些行动来解决问题。如果你无法修复测试，至少：

1. 从单元测试中忽略它们（有不同的方法可以做到这一点）。
2. 根据需要输入尽可能多的问题并指派人员来修复测试。

然后阻止此类情况将来发生，请安装类似于Hudson Game Plugin的插件。人们在持续集成期间获得分配点，例如

• -10打破了构建＆lt; - 更糟糕的
• -1打破测试
• +1修复测试
• 等

非常酷的工具，可以在团队中创建关于单元测试的责任感。

Answer 4

• 将它们注释掉，以便以后修复。
• 生成测试覆盖率报告（例如Cobertura）。您注释掉的测试所涵盖的方法将被表示为未被测试覆盖。

Answer 5

如果他们编译但失败了：留下他们。这将使您在使用CI时获得测试改进的良好历史。如果测试没有编译但是打破了构建，请将它们注释掉并捅开发器来修复它们。

这显然不排除使用选项3（击中头部），无论如何，无论你对测试做什么，都应该这样做。

Answer 6

你现在应该以某种方式禁用它们。是否通过评论，删除（假设您可以从源代码管理中取回它们）或其他方式完成，取决于您。您不希望这些失败的测试成为尝试提交新更改的人的障碍。

如果你觉得自己能够自己修复它们，那就太好了 - 做得好。如果它们太多，那么我倾向于使用“众包”方法。为每个失败的测试提交一个错误。如果可能的话，尝试将这些错误分配给测试/测试代码的实际所有者/作者，但是如果确定太难，那么只要您告诉人们重新分配错误分配给他们的错误，随机选择就可以了。然后鼓励人们通过给他们一个截止日期或定期通知每个人的进展并鼓励他们修复所有错误来修复这些错误。

Answer 7

稳定的红色CI系统毫无价值。主要的好处是保持质量标准，如果没有过渡标志质量下降，这将变得更加困难。

因此，立即努力应该是禁用失败的测试，并为每个测试创建跟踪单/工作项。然而，如果没有人关心测试，那么每一个都会得到解决 - 摆脱它。如果故障表示在发货前需要解决的问题，则禁用测试。

一旦您处于此状态，您现在可以依靠CI系统告诉您需要采取紧急措施 - 回滚最后一次更改，或立即让团队解决问题，或其他任何事情。

Answer 8

我不知道你在公司中的位置，但如果有可能将他们留在并将问题归档为您的票务系统中的错误。让开发人员可以修复它们或删除测试。

如果这不起作用删除它们（你有版本控制，对吗？）并用一个评论来关闭票证，例如“删除了失败的junit测试，显然不会被修复”或者更礼貌的东西。

关键是，junit测试是应用程序代码，因此应该可行。这就是开发商获得报酬的原因。如果测试不再合适（某些不再存在的测试），开发人员应发出信号并删除测试。