java JUnit 的 @Ignore

JUnit's @Ignore

提问by dlinsin

I wonder if it is a good practice to use JUnit's @Ignore. And how people are using it?

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

I came up with the following use case: Let's say I am developing a class and writing a JUnit test for it, which doesn't pass, because I'm not quite done with the class. Is it a good practice to mark it with @Ignore?

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

I'm a little concerned that we might miss the ignored test case later on or that people start using it to "force" tests to pass CI.

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

回答by Adeel Ansari

Thats pretty much fine, I suppose.

那很好，我想。

The docssays,

该文件说，

Test runners will report the number of ignored tests, along with the number of tests that ran and the number of tests that failed.

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

Hence, it means even if you forget to remove that afterwards, you should have been notified about that.

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

The example given in the docs, is completely resembling your case.

文档中给出的示例与您的案例完全相似。

@Ignore("not ready yet")

回答by sleske

I routinely use @Ignore for tests which fail because of a known bug. Once the bug is acknowledged and logged in the bug databases, the test failure serves no purpose, since the bug is already known.

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

Still it makes sense to keep the test code, because it will be useful again once the bug is fixed. So I mark it to be ignored, with a comment indicating the related bug, and ideally note in the bug report that the test should be reactivated to test the fix.

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

回答by Gishu

IMHO, Ignore that should not be used lightly... due to the broken windows effect.

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

I rarely find myself using this attribute/annotation in xUnit. The only few times I've used them is as a TODOwhen writing TestCase#1, I see another test case(s) that I missed but which should also be included. Just so that I dont forget it, I write a small test case with a descriptive name and mark it with Ignore. Proceed to complete TestCase#1. But this is all intra-check-in. I never check in tests marked with Ignore.

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

However usually I just use a piece of paper - test listto jot down the new test case - which is much simpler. This also caters to the scenario where I'm partially done... completed 5 of 10 tests. Instead of checkin in 5 Ignored tests, I'd keep the test-list around and check in 5 passing tests. The assumption is that you'll complete the rest in the next few check-ins before jumping to something new.

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

Other 'special cases' I can think of is..
When you're waiting for a componentfrom another team/person/vendor (whose interface has been published-agreed to), without which the tests can't run. In this case, you can write the tests and mark it with Ignore("Waiting on X to deliver component Y")

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

回答by matt burns

I think that it a perfectly good way to use it.

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

Your CI server should be green (or blue in Hudson's case) all the time. Whenever it isn't your first priority is to fix it.

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

Now, if CI broke because of a bug in the test code (perhaps the test code is naughty and non-deterministic) then you should just ignore the test "@Ignore(This test code is borken, raised defect #123)" and raise the bug in your defect tracker.

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

You won't ship broken code because whenever you ship, you review all defects and decide if any of them are show stoppers right? A broken test that isn't running, will be considered along with the code / feature it was testing. You ship if and only if you're happy that the code it was testing is not also broken. If it ain't tested, consider it broken.

您不会发送损坏的代码，因为无论何时发送，您都会查看所有缺陷并决定其中是否有任何缺陷，对吗？未运行的损坏测试将与它正在测试的代码/功能一起考虑。当且仅当您很高兴它正在测试的代码没有被破坏时，您才发货。如果它没有经过测试，就认为它坏了。

I'm hoping the junit xml report formatter, used when running tests from ant, will one day include the ignored count (and the reasons) along with pass, fail, and error. Maybe then, CI vendors will include the ignored test counts (if not I may have to write a Hudson plugin...)

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

回答by kender

Well, if you're not done with the class it's good the test fails. Marking it as @Ignore would mean you will ship a code with unfinished class. And right, maybe you're not using that class yet in any code that gets executed, but someday some other developer might see that class and use it. Then he fails even it should work.

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

I wouldn't use @Ignore in that case for sure.

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

回答by Nikhil

I think using @ignore is OK as long as there is -

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

1. A good reason why the method cannot be tested in some form and it is documented as such in the code. This should be a special case and warrant a discussion or code review to see if there is any way to test it.
2. The test is not yet built - this should ideally happen only for legacy code. This should be also subject to code review and tasks should be put to add tests.

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

That's the rules at least in my mind ;-)

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

回答by Thomas Schultz

I think this goes against the core fundamentals of test driven development. Granted if you're not doing TDD then it probably doesn't matter so much.

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

I would say though that if you're using @ignore then you're not LEAN and not doing TDD.

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

If you're doing TDD then you shouldn't ever have failing tests in any commit that you make to your repo.

如果你在做 TDD，那么你对你的 repo 所做的任何提交都不应该有失败的测试。

Am I totally crazy or does this make sense?

我是完全疯了还是这有意义？

回答by Anna

I think it's ok to use @Ignore's when the test relies on external entities that can't be mocked. We still need the test to make sure things are working but we dont't want to deploy a test which relies on an external dependency.

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

For example, if you write a custom SpreadsheetWriter/Reader for Google docs it makes sense to use a real google doc to test it with. However you wouldn't want your build to fail if google docs are down for whatever reason. After confirming that your unit test passes locally I would add an @Ignore before pushing it to production.

例如，如果您为 Google 文档编写了一个自定义的 SpreadsheetWriter/Reader，那么使用真正的 google 文档来测试它是有意义的。但是，如果 google 文档因任何原因关闭，您不希望构建失败。在确认您的单元测试在本地通过后，我会在将其推送到生产之前添加一个 @Ignore。

In general,I think @Ignore should be avoided as much as possible because in most cases external classes/systems can be mocked.

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

回答by korda

@Ignorecan be used on tests written for some third party services. I recently found myself in need to check if external service is sending back the data I expect. It was very convenient to do that in test (mocks). Since I knewthat my input data won't work forever and I may need to run similar test later I added @Ignoreinstead of deleting test.

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