2

I am trying to write a unit test for a method which takes a string as a para- meter and throws an exception if it is malformed (AND NONE if it is okay). I want to write a parameterized test which feeds in several strings and the expected exception (INCLUDING the case that none is thrown if the input string is well-formed!). If trying to use the @Test(expect=SomeException.class) annotation, I encountered two problems:

  1. expect=null is not allowed. So how could I test for the expected outcome of NO exception to be thrown (for well-formed input strings)?

  2. expect= not possible? I not yet tried it, but I strongly suspect that this is the case after reading this (could you please state whether this is true?): http://tech.groups.yahoo.com/group/junit/message/19383 This then seems to be the best solution I found yet. What do you think about it, especially compared to that: How do I test exceptions in a parameterized test?

Thank you in advance for any help, I look forward the discussion :)

Community
  • 1
  • 1
juniper
  • 311
  • 5
  • 13

3 Answers3

6

Create two test case classes:

  • ValidStringsTest
  • InvalidStringsTest

Obviously the first one tests all sorts of valid inputs (not throwing an exception), whilst the second one always expects the exception.

Remember: readability of your tests is even more important than readability of production code. Don't use wacky flags, conditions and logic inside JUnit test cases. Simplicity is the king.

Also see my answer here for a hint how to test for exceptions cleanly.

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
1

Have two different tests - one for valid inputs and one for invalid ones. I haven't used JUnit 4 so I can't comment on the exact annotation format - but basically you'd have one parameterized test with various different invalid inputs, which says that it does expect an exception, and a separate test with various different valid inputs which doesn't say anything about exceptions. If an exception is thrown when your test doesn't say that it should be, the test will fail.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
0

Splitting the test cases into two test classes is the appropriate approach in many cases - as both Tomasz and Jon already outlined.

But there are other cases where this split is not a good choice just in terms of readability. Let's assume the rows in the tested data set have a natural order and if the rows are sorted by this natural order it may be easy to see whether or not the test data covers all relevant use cases. If one splits the test cases into two test classes, there is no longer an easy way to see whether all relevant test cases are covered. For these cases How do I test exceptions in a parameterized test? seeems to provide the best solution indeed.

Community
  • 1
  • 1
rwitzel
  • 1,694
  • 17
  • 21