DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Building Scalable Real-Time Apps with AstraDB and Vaadin
Register Now

Trending

  • How To Check IP Addresses for Known Threats and Tor Exit Node Servers in Java
  • 4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
  • Using OpenAI Embeddings Search With SingleStoreDB
  • Integration Testing Tutorial: A Comprehensive Guide With Examples And Best Practices

Trending

  • How To Check IP Addresses for Known Threats and Tor Exit Node Servers in Java
  • 4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
  • Using OpenAI Embeddings Search With SingleStoreDB
  • Integration Testing Tutorial: A Comprehensive Guide With Examples And Best Practices
  1. DZone
  2. Coding
  3. Java
  4. Unexpected Behavior in JUnit’s ExpectedException

Unexpected Behavior in JUnit’s ExpectedException

Alex Ruiz user avatar by
Alex Ruiz
·
Oct. 29, 10 · Interview
Like (0)
Save
Tweet
Share
8.11K Views

Join the DZone community and get the full member experience.

Join For Free

In a previous post, I described my preference of the relative new ExpectedException rule over the more traditional strategies for verifying expected exceptions: the good-old “try-fail-catch” pattern and the “expected” attribute in JUnit’s @Test annotation. I thought, and I still think, that this new tool provides the best features of its predecessors: code brevity and the ability to specify which line of code is the one we expect to throw an exception. The only point I missed: it is not foolproof.

In a previous conversation with my good friend and colleague Stuart, we agreed that we need to be careful enough to place the check for an expected exception just before the line of code that is supposed to throw such exception, in order to verify that the exception is thrown at the correct time. The following example is taken from FEST’s Assertions:

// Note: I'm using the ExpectedException rule I created myself in the previous post.
@Rule public ExpectedException thrown = none();

private StringAssert assertions;

@Before public void setUp() {
assertions = new StringAssert("Leia");
}

@Test public void should_fail_if_actual_is_not_equal_to_expected() {
thrown.expectAssertionError("expected:<'Yoda'> but was:<'Leia'>");
assertions.isEqualTo("Yoda");
}

So far, so good. A couple of nights ago, I discovered by accident that any code placed after the line that throws the exception will never get executed if the expected exception is actually thrown. For example, in the following code listing, I was checking that the mocks were correctly called after the expected exception is thrown (BTW, I’m using Mockito.)

@Rule public ExpectedException thrown = none();

private StringAssert assertions;
private Failures failures;

@Before public void setUp() {
assertions = new StringAssert("Leia");
failures = spy(Failures.instance());
assertions.failures = failures;
}

@Test public void should_fail_if_actual_is_not_equal_to_expected() {
thrown.expectAssertionError("expected:<'Yoda'> but was:<'Leia'>");
assertions.isEqualTo("Yoda");
verify(failures).fail(assertions.info, isNotEqual(assertions.actual, "Yoda"));
}

The problem here is that line 15 will never be executed if line 14 throws the expected exception! This test will always pass as long as the expected exception is thrown, even if I remove the calls to Failures from StringAssert.

The reason behind this behavior is actually quite simple. By looking at the source of ExpectedException, we can tell immediately that once the expected exception is caught, it is impossible to continue the execution of the test method:

@Override public void evaluate() throws Throwable {
try {
fNext.evaluate();
} catch (Throwable e) {
if (fMatcher == null) throw e;
Assert.assertThat(e, fMatcher);
return;
}
if (fMatcher != null)
throw new AssertionError("Expected test to throw "
+ StringDescription.toString(fMatcher));
}

I fixed this test by replacing the ExpectedException rule with the traditional “try-fail-catch” pattern:

@Test public void should_fail_if_actual_is_not_equal_to_expected() {
try {
assertions.isEqualTo("Yoda");
fail();
} catch (AssertionError e) {
assertEquals("expected:<'Yoda'> but was:<'Leia'>", e.getMessage());
}
verify(failures).fail(assertions.info, isNotEqual(assertions.actual, "Yoda"));
}

Not surprisingly, it turns out that Stuart had a similar thought about the subject. After a brief chat, we came up with the following patterns for using ExpectedException effectively:

  1. the check for the expected exception must be immediately above the code that is expected to throw such exception
  2. the line of code that is expected to throw an exception should be the last line in the test method

From http://alexruiz.developerblogs.com/?p=1678

JUnit

Opinions expressed by DZone contributors are their own.

Trending

  • How To Check IP Addresses for Known Threats and Tor Exit Node Servers in Java
  • 4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
  • Using OpenAI Embeddings Search With SingleStoreDB
  • Integration Testing Tutorial: A Comprehensive Guide With Examples And Best Practices

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: