blocks|key|1658322|text|好吧，如果你还没有完成这个类，那么测试失败是件好事。将其标记为@Ignore将意味着您将使用未完成的类发布代码。对了，也许你还没有在执行的任何代码中使用这个类，但总有一天其他开发人员可能会看到这个类并使用它。那么，即使它应该起作用，他也会失败。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1658323|在这种情况下，我肯定不会使用@Ignore。|1658324|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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. 

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

blocks|key|1658482|text|我认为这是一个很好的使用它的方式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1658483|您的CI服务器应始终为绿色(在Hudson的情况下为蓝色)。当它不是的时候，你的首要任务就是修复它。|1658484|现在，如果CI由于测试代码中的错误而中断(可能测试代码是顽皮的和不确定的)，那么您应该忽略测试“@+ignore+(此测试代码被破坏，引发缺陷#123)”，并在您的缺陷跟踪器中引发错误。|1658485|你不会发布损坏的代码，因为每当你发布的时候，你都会检查所有的缺陷，并决定他们中是否有任何一个是显示停止的，对吗？未运行的失败测试将与其正在测试的代码/功能一起考虑。当且仅当你很高兴它测试的代码没有被破坏时，你才会发布。如果它没有经过测试，就认为它坏了。|1658486|我希望在ant中运行测试时使用的junit+xml报告格式化程序有一天会包括被忽略的计数(以及原因)以及通过、失败和错误。也许到那时，CI供应商将包括被忽略的测试计数(如果不是，我可能不得不编写一个Hudson插件...)|1658487|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

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.

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.

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...)

blocks|key|1658593|text|对于由于已知bug而失败的测试，我通常使用@Ignore。一旦错误被确认并记录在错误数据库中，测试失败就没有意义了，因为这个错误是已知的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1658594|尽管如此，保留测试代码还是有意义的，因为一旦修复了bug，它就会再次有用。因此，我将其标记为忽略，并添加注释以指示相关的bug，理想情况下，还应在bug报告中注明应重新激活测试以测试修复。|1658595|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

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.

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.

blocks|key|1443969|text|我认为这违背了测试驱动开发的核心原则。当然，如果你不做TDD，那么它可能就没那么重要了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1443970|我要说的是，如果你使用@ignore，那么你就不是瘦的，也不是在做TDD。|1443971|如果你正在做TDD，那么你就不应该在你提交给你的repo的任何提交中有失败的测试。|1443972|我是不是完全疯了，还是这有道理？|1443973|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

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.

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

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

Am I totally crazy or does this make sense?

blocks|key|1444076|text|我认为当测试依赖于无法模拟的外部实体时，使用@Ignore是可以的。我们仍然需要测试来确保一切正常工作，但我们不想部署依赖于外部依赖的测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1444077|例如，如果你为Google文档编写了一个自定义的SpreadsheetWriter/Reader，那么使用一个真正的google文档来测试它是有意义的。然而，如果google+docs由于某种原因停机，你不会希望你的构建失败。在确认您的单元测试在本地通过之后，我会在将其推送到生产环境之前添加一个@Ignore。|1444078|总的来说，我认为应该尽可能避免@Ignore，因为在大多数情况下，外部类/系统可以被模仿。|1444079|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

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.

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.

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

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

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? 

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.

JUnit's @Ignore

单元测试

数据库

服务器

我想知道使用JUnit的@Ignore是否是一个好的实践。以及人们是如何使用它的？我想出了下面的用例:假设我正在开发一个类并为它编写一个JUnit测试，这个测试没有通过，因为我还没有完全完成这个类。用@Ignore标记它是一种好的做法吗？我有点担心我们以后可能会错过被忽略的测试用例，或者人们开始使用它来“强迫”测试通过...

问JUnit的@Ignore
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JUnit的@IgnoreEN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问JUnit的@Ignore
EN