Great Expectations

What’s the best way to handle expected exceptions in JUnit?

If you want to inspect the contents of the exception and make assertions against it then there is only one clean way; Use the ExpectedException JUnit Rule.

I’ve seen it used badly, though. Think about how to name the field. I see no better name than simply “thrown”. When you use it in your tests it reads perfectly sensibly as




is a bit clumsy, and


is not expressive.

The other mistake people make is to not tidy things up with reusable custom Hamcrest matchers. They’re so easy to create (a future post on that issue coming soon), for your common domain-specific exceptions they can be easily reused, and they make the code expressive and simple. You can simply use any Matcher<?>.

One of the simplest options is to use the Hamcrest “hasProperty” matcher to assert against properties of the exception.

public ExpectedException thrown = ExpectedException.none();

public void shouldGoWrongSometimes() throws Exception {

  thrown.expectMessage("That was bad input");


  thrown.expect(hasProperty("xyz", equalTo("oh dear")));

  testSubject.use("bad data");
Posted in Clean Test Code, Hamcrest, JUnit, JUnit Rule

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: