15

This might be a conceptually stupid question, but it also might not and since I am still a student I think I should I have no problem asking.

Imagine you have a method that if given certain conditions it will throw an NumberFormatException. I want to write a Unit Test to see if the exception is being correctly thorwn. How can I achieve this?

P.S. I am using JUnit to write the Unit Tests.

Thanks.

Andrew Edgecombe
  • 39,594
  • 3
  • 35
  • 61
nunos
  • 20,479
  • 50
  • 119
  • 154

7 Answers7

31

As other posters suggested, if you are using JUnit4, then you can use the annotation:

@Test(expected=NumberFormatException.class);

However, if you are using an older version of JUnit, or if you want to do multiple "Exception" assertions in the same test method, then the standard idiom is:

try {
   formatNumber("notAnumber");
   fail("Expected NumberFormatException");
catch(NumberFormatException e) {
  // no-op (pass)
}
Michael D
  • 1,932
  • 16
  • 12
  • This is a good idiom for when you want to test things about the exception, such as its message, not just its existence. – Yishai Oct 28 '10 at 22:02
  • +1 - Good point about the older version. – Feanor Oct 28 '10 at 22:02
  • +1 - An answer to this question is not complete without the second example. In practice I need to default to this approach more often than not for the reasons mentioned. – Synesso Oct 28 '10 at 22:20
  • 3
    The problem with doing this, is that I've seen a lot of people mess up the boilerplate. (ie: forgetting to call fail, or catching too general of an exception). Personally, I prefer to create a method that takes a Runnable or Callable (for checked exceptions) and asserts that it throws a given exception. (ie: assertException(NumberFormatException.class, new Callable() { ... formatNumber("notAnumber"); });. It's just as much boilerplate, but "feels safer" – Michael D Oct 28 '10 at 22:21
  • I generally check the message and maybe other fields of the caught exception. – Stephen C Oct 28 '10 at 22:33
  • 2
    @Michael D: Would you care to elaborate your comment and maybe add a answer of your own. I think like your idea. – nunos Oct 28 '10 at 22:45
10

Assuming you are using JUnit 4, call the method in your test in a way that causes it to throw the exception, and use the JUnit annotation

@Test(expected = NumberFormatException.class)

If the exception is thrown, the test will pass.

Feanor
  • 2,715
  • 4
  • 29
  • 43
9

If you can use JUnit 4.7, you can use the ExpectedException Rule

@RunWith(JUnit4.class)
public class FooTest {
  @Rule
  public ExpectedException exception = ExpectedException.none();

  @Test
  public void doStuffThrowsIndexOutOfBoundsException() {
    Foo foo = new Foo();

    exception.expect(IndexOutOfBoundsException.class);
    exception.expectMessage("happened?");
    exception.expectMessage(startsWith("What"));
    foo.doStuff();
  }
}

This is much better than @Test(expected=IndexOutOfBoundsException.class) because the test will fail if IndexOutOfBoundsException is thrown before foo.doStuff()

See this article and the ExpectedException JavaDoc for details

NamshubWriter
  • 23,549
  • 2
  • 41
  • 59
3

Use @Test(expected=IOException.class)

http://junit.sourceforge.net/doc/faq/faq.htm#tests_7

This is fine if you have one expected exception. An alternative strategy is to add an Assert.fail() at the end of the test method. If an exception isn't thrown then the test will fail accordingly. e.g.

@Test
public void testIOExceptionThrown() {      
   ftp.write(); // will throw IOException      
   fail();
}
Jonathan Holloway
  • 62,090
  • 32
  • 125
  • 150
3

You can do this:

 @Test(expected=IndexOutOfBoundsException.class)
    public void testIndexOutOfBoundsException() {
        ArrayList emptyList = new ArrayList();
        Object o = emptyList.get(0);
    }
Adam
  • 43,763
  • 16
  • 104
  • 144
1

Add this annotation before your test method; it'll do the trick.

@Test(expected = java.lang.NumberFormatException.class)
public void testFooMethod() {
    // Add code that will throw a NumberFormatException
}
duffymo
  • 305,152
  • 44
  • 369
  • 561
0

A solution that is not bound to a particular JUnit version is provided by catch-exception which has been made to overcome some disadvantages that are inherent in the JUnit mechanisms.

rwitzel
  • 1,694
  • 17
  • 21