JUnit 的@Ignore答案

【问题标题】：JUnit's @IgnoreJUnit 的@Ignore
【发布时间】：2010-09-29 13:41:34
【问题描述】：

我想知道使用 JUnit 的 @Ignore 是否是一个好习惯。人们如何使用它？

我想出了以下用例：假设我正在开发一个类并为它编写一个 JUnit 测试，但没有通过，因为我还没有完成这个类。用@Ignore 标记它是一个好习惯吗？

我有点担心我们以后可能会错过被忽略的测试用例，或者人们开始使用它来“强制”测试通过 CI。

【问题讨论】：

标签： java unit-testing testing

【解决方案1】：

我想这很好。

docs 说，

测试运行者将报告被忽略的测试数量以及测试数量运行的测试次数和失败的测试次数。

因此，这意味着即使您之后忘记删除它，您也应该收到通知。

docs 中给出的示例与您的情况完全相似。

@Ignore("not ready yet")

【讨论】：

【解决方案2】：

对于由于已知错误而失败的测试，我经常使用@Ignore。一旦错误被确认并记录在错误数据库中，测试失败就没有任何意义，因为错误是已知的。

保留测试代码仍然有意义，因为一旦修复了错误，它将再次有用。因此，我将其标记为忽略，并在注释中指出相关的错误，并在错误报告中注明应重新激活测试以测试修复。

【讨论】：

【解决方案3】：

恕我直言，忽略不应该轻易使用的...由于破窗效果。

我很少发现自己在 xUnit 中使用此属性/注释。我使用它们的唯一几次是在编写 TestCase#1 时作为 TODO，我看到了另一个我错过但也应该包括在内的测试用例。为了不忘记，我写了一个带有描述性名称的小测试用例，并用 Ignore 标记它。继续完成 TestCase#1。但这都是内部签到。我从不签入标有“忽略”的测试。

但是通常我只是使用一张纸 - 测试列表来记下新的测试用例 - 这要简单得多。这也迎合了我部分完成的场景......完成了 10 个测试中的 5 个。我不会签入 5 个忽略的测试，而是保留测试列表并签入 5 个通过的测试。假设您将在接下来的几次签到中完成其余部分，然后再跳到新事物。

我能想到的其他“特殊情况”是..
当您等待来自另一个团队/人员/供应商（其接口已发布-同意）的组件时，如果没有该组件，测试将无法运行。在这种情况下，您可以编写测试并将其标记为 Ignore("Waiting on X to deliver component Y")

【讨论】：

在这种情况下，它会变成别的东西，而不是单元测试。您是指由两个或更多人开发的 1 个单元还是用一个案例测试多个单元。恐怕不是一个好主意。
我的意思是'想象一下你正在为需要 ClassB 作为合作者的 ClassA 编写测试。然而，ClassB 是由其他人并行开发的。你可以使用模拟，但你仍然应该与真正的合作者一起测试。 Ignore("直到 ClassB 完成")
我倾向于同意。谢谢你的解释。

【解决方案4】：

我认为这是一个非常好的使用方式。

您的 CI 服务器应该一直是绿色的（或者在 Hudson 的情况下是蓝色的）。只要不是你的首要任务就是修复它。

现在，如果 CI 因测试代码中的错误而中断（也许测试代码是顽皮且不确定的），那么您应该忽略测试“@Ignore（此测试代码已损坏，引发缺陷 #123） " 并在您的缺陷跟踪器中提出错误。

您不会发布损坏的代码，因为无论何时发布，您都会检查所有缺陷并确定其中是否有任何缺陷，对吗？未运行的损坏测试将与它正在测试的代码/功能一起考虑。当且仅当您对它正在测试的代码也没有损坏感到高兴时，您才发货。如果没有经过测试，则认为它已损坏。

我希望在从 ant 运行测试时使用的 junit xml 报告格式化程序有一天会包括忽略的计数（和原因）以及通过、失败和错误。也许到那时，CI 供应商将包括被忽略的测试计数（如果没有，我可能不得不编写一个 Hudson 插件......）

【讨论】：

+1 - @Ignore 应该用于（暂时）跳过您不相信是有效的测试，而不是被测单元本身的问题。
“当且仅当您对它正在测试的代码也可能被破坏感到高兴时，您才发布。”：这是倒退吗？
是的，这是一个错字，现在更正了。有人发现它只用了 3 年，干杯！

【解决方案5】：

好吧，如果你没有完成这门课，那很好，测试失败了。将其标记为@Ignore 意味着您将发布一个未完成类的代码。是的，也许你还没有在任何被执行的代码中使用那个类，但是有一天其他开发人员可能会看到那个类并使用它。然后他失败了，即使它应该工作。

我肯定不会在这种情况下使用@Ignore。

【讨论】：

我认为，它的目的是为了将两者分开，实际失败和不完整。所以，他们不会混淆。因为可能有人开始考虑修复它，而实际上它是不完整的，而不是错误的代码。或者可能是关于个人喜好以及对人来说自然的感觉。
@Adeel Ansari：我同意@kender。我不是 JUnit 方面的专家，但我认为这种情况最好由 @Incomplete 或 @NotReadyForTesting 而不是 @Ignore 来处理。并且该注释属于 Class，而不是 Test。
@Hemal Pandya 确切地说，如果实现没有完成，那么应该是注释的类，而不是测试。
感谢各位大侠的指点，我一直在思考这个问题，但没有找到合适的解决方案。我不想把不完整和失败混为一谈，因为它不一样。另一方面，我不希望测试落在桌子底下。这可能是正确工具的问题。
PP 可能听起来很奇怪。实际上，它的个人喜好。剩下的字符不多了:)

【解决方案6】：

我认为使用@ignore 是可以的，只要有 -

无法以某种形式测试该方法的一个很好的理由，并且在代码中记录了该方法。这应该是一种特殊情况，需要进行讨论或代码审查，看看是否有任何方法可以对其进行测试。
测试尚未构建 - 理想情况下，这应该只适用于遗留代码。这也应该接受代码审查，并且应该将任务添加到添加测试中。

至少在我看来这是规则；-)

【讨论】：

【解决方案7】：

我认为这违背了测试驱动开发的核心基础。当然，如果你不做 TDD，那么它可能没那么重要。

我想说的是，如果你使用@ignore，那么你就不是精益，也不是在做 TDD。

如果您正在执行 TDD，那么您不应该在对您的存储库所做的任何提交中出现失败的测试。

我完全疯了还是有道理？

【讨论】：

大多数项目并非如此。通常不只是一个分支。虽然你是对的，不应该有失败的测试（但应该只针对主/主分支）。其他不构成发布的分支通常会有失败的测试。
我是从 TDD 的角度说的。即使 2 年后，如果您正在执行 TDD，我仍然认为不需要 @Ignore。如果你不做 TDD 那么为什么不把测试注释掉 shrug。我没用过。这只是我到目前为止的经验。

【解决方案8】：

我认为当测试依赖于无法模拟的外部实体时使用@Ignore 是可以的。我们仍然需要测试以确保一切正常，但我们不想部署依赖于外部依赖项的测试。

例如，如果您为 Google 文档编写自定义的电子表格编写器/阅读器，那么使用真正的 google 文档对其进行测试是有意义的。但是，如果 google 文档由于某种原因而关闭，您不希望您的构建失败。在确认您的单元测试在本地通过后，我会在将其推送到生产之前添加一个@Ignore。

总的来说，我认为应该尽可能避免使用@Ignore，因为在大多数情况下，外部类/系统可以被模拟。

【讨论】：

【解决方案9】：

@Ignore 可用于为某些第三方服务编写的测试。我最近发现自己需要检查外部服务是否正在发回我期望的数据。在测试（模拟）中这样做非常方便。因为我知道我的输入数据不会永远有效，并且我可能需要稍后运行类似的测试，所以我添加了 @Ignore 而不是删除测试。

【讨论】：