Skip to content

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

Closed
sbrannen wants to merge 1 commit into
junit-team:masterfrom
sbrannen:1066
Closed

Ensure exceptions from methodBlock() don't result in unrooted tests#1082
sbrannen wants to merge 1 commit into
junit-team:masterfrom
sbrannen:1066

Conversation

@sbrannen

Copy link
Copy Markdown
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

kcooney commented Feb 15, 2015

Copy link
Copy Markdown
Member

Thanks? Could you add a test?

@sbrannen

Copy link
Copy Markdown
Member Author

Sure. I just introduced CustomBlockJUnit4ClassRunnerTest and squashed the commits.

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

kcooney commented Feb 16, 2015

Copy link
Copy Markdown
Member

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

@sbrannen

Copy link
Copy Markdown
Member Author

OK. I added CustomBlockJUnit4ClassRunnerTest to the AllTests suite.

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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

kcooney commented Feb 20, 2015

Copy link
Copy Markdown
Member

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
Copy Markdown
Member

Which Tuesday? ;-)

@kcooney kcooney closed this in a90b496 Mar 1, 2015
@kcooney

kcooney commented Mar 1, 2015

Copy link
Copy Markdown
Member

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

@sbrannen

sbrannen commented Mar 1, 2015

Copy link
Copy Markdown
Member Author

Great! Thanks for merging it.

@kcooney

kcooney commented Mar 1, 2015

Copy link
Copy Markdown
Member

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

@sbrannen

sbrannen commented Mar 1, 2015

Copy link
Copy Markdown
Member Author

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