When verifying that code raises a runtime exception, a good practice is to avoid having multiple method calls inside the tested code, to be explicit about which method call is expected to raise the exception.


It increases the clarity of the test, and avoid incorrect testing when another method is actually raising the exception.


== Noncompliant Code Example

----
@Test
public void testToString() {
  // Do you expect get() or toString() throwing the exception?
  org.junit.Assert.assertThrows(IndexOutOfBoundsException.class, () -> get().toString()); 
}

@Test
public void testToStringTryCatchIdiom() {
  try {
    // Do you expect get() or toString() throwing the exception?
    get().toString(); 
    Assert.fail("Expected an IndexOutOfBoundsException to be thrown");
  } catch (IndexOutOfBoundsException e) {
    // Test exception message...
  }
}
----


== Compliant Solution

----
@Test
public void testToString() {
   Object obj = get();
   Assert.assertThrows(IndexOutOfBoundsException.class, () -> obj.toString());
}

@Test
public void testToStringTryCatchIdiom() {
  Object obj = get();
  try {
    obj.toString();
    Assert.fail("Expected an IndexOutOfBoundsException to be thrown");
  } catch (IndexOutOfBoundsException e) {
    // Test exception message...
  }
}
----


== See

* https://github.com/junit-team/junit4/wiki/Exception-testing[JUnit exception testing documentation]


ifdef::env-github,rspecator-view[]
== Comments And Links
(visible only on this page)

include::comments-and-links.adoc[]
endif::env-github,rspecator-view[]
