Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure exceptions from methodBlock() don't result in unrooted tests #1082

Closed
wants to merge 1 commit into from

Conversation

sbrannen
Copy link
Member

The introduction of the runLeaf() method in BlockJUnit4ClassRunner in
JUnit 4.9 introduced a regression with regard to exception handling.

Specifically, the invocation of methodBlock() is no longer executed
within a try-catch block as was the case in previous versions of JUnit.

Custom modifications to methodBlock() or the methods it invokes may in
fact throw exceptions. In such cases, exceptions thrown from
methodBlock() cause the current test execution to abort immediately. As
a result, the failing test method is unrooted in test reports, and
subsequent test methods are never invoked. Furthermore, RunListeners
registered with JUnit are not notified.

This commit addresses this issue by wrapping the invocation of
methodBlock() within a try-catch block. If an exception is not thrown,
the resulting Statement is passed to runLeaf(). If an exception is
thrown, it is wrapped in a Fail statement which is passed to runLeaf().

Issue: #1066

@kcooney
Copy link
Member

kcooney commented Feb 15, 2015

Thanks? Could you add a test?

@sbrannen
Copy link
Member Author

Sure. I just introduced CustomBlockJUnit4ClassRunnerTest and squashed the commits.

* Simple {@link RunListener} which tracks how many times certain JUnit callback
* methods were called: only intended for the integration test suite.
* <p>This code has been copied directly from the Spring Framework.
* @author Sam Brannen
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you the author of this class in the Spring Framework? Otherwise, this might be a bit fishy license-wise, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am in fact the author of the code in question, but as far as I understand that is irrelevant since the ASL license header is included in the file along with the @author tags.

Now, I am not a lawyer, but I don't think there is any issue here since:

  1. The original ASL 2.0 license header is present in the file I submitted.
  2. The code in question is not distributed per se with JUnit JARs; it resides in the test suite.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But JUnit isn't released under ASL. Could we use a simpler runner where each of the methods appends a hard-coded string to an ArrayList, then you can do assertions on the list.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have rewritten the TrackingRunListener from scratch. Any remaining similarities to code in Spring's testing suite are therefore coincidental due to the nature of the task at hand.

@kcooney
Copy link
Member

kcooney commented Feb 16, 2015

I think you manually need to add the test to the test suite in order for maven to run the test

@sbrannen
Copy link
Member Author

OK. I added CustomBlockJUnit4ClassRunnerTest to the AllTests suite.

/*
* Copyright 2002-2015 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JUnit isn't licensed under the Apache License. Please remove this entire comment block

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been replaced with a license header compliant with the Eclipse Foundation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have copyright and licenses in any of the other files that I'm aware of. I'll remove it when I merge this.

The introduction of the runLeaf() method in BlockJUnit4ClassRunner in
JUnit 4.9 introduced a regression with regard to exception handling.

Specifically, the invocation of methodBlock() is no longer executed
within a try-catch block as was the case in previous versions of JUnit.

Custom modifications to methodBlock() or the methods it invokes may in
fact throw exceptions. In such cases, exceptions thrown from
methodBlock() cause the current test execution to abort immediately. As
a result, the failing test method is unrooted in test reports, and
subsequent test methods are never invoked. Furthermore, RunListeners
registered with JUnit are not notified.

This commit addresses this issue by wrapping the invocation of
methodBlock() within a try-catch block. If an exception is not thrown,
the resulting Statement is passed to runLeaf(). If an exception is
thrown, it is wrapped in a Fail statement which is passed to runLeaf().

Issue: junit-team#1066
@kcooney
Copy link
Member

kcooney commented Feb 20, 2015

Thanks for the changes. I think the remaining (quite minor) issues can be resolved when we merge this. I'll try to find time Tuesday night to do that.

@marcphilipp
Copy link
Member

Which Tuesday? ;-)

@kcooney kcooney closed this in a90b496 Mar 1, 2015
@kcooney
Copy link
Member

kcooney commented Mar 1, 2015

Merged. Thanks! Sorry for the delay; both home and work life have been busy for me

@sbrannen
Copy link
Member Author

sbrannen commented Mar 1, 2015

Great! Thanks for merging it.

@kcooney
Copy link
Member

kcooney commented Mar 1, 2015

@sbrannen do you mind updating the JUnit 4.13 release notes to mention this pull?

@sbrannen
Copy link
Member Author

sbrannen commented Mar 1, 2015

Mentioned this pull request in the release notes here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants