Extend ExpectedException's documentation and fix #687. #720

stefanbirkner · 2013-08-17T12:57:05Z

No description provided.

dsaff · 2013-08-20T22:10:17Z

src/main/java/org/junit/rules/ExpectedException.java

@@ -199,19 +325,27 @@ private void optionallyHandleException(Throwable e, boolean handleException)
            throws Throwable {
        if (handleException) {
            handleException(e);
-        } else {
+        } else if (!isExpectedException(e)) {


Sorry, missed this, which is the essential line of the pull. Nice.

dsaff · 2013-08-20T22:13:01Z

I wonder how you'd feel about deprecating the explicit handleAssertion and handleAssumption methods, in favor of a single dontWrap(Matcher). (where the default dont-wrap matcher would be the current default of all AssertionErrors and AssumptionExceptions). This has two advantages:

More flexible if people are using a framework that assigns meaning to some other exception.
Hopefully takes up less "mental space" in the documentation and API--it's one method to change a particular setting, rather than 2 that configure 2 orthogonal ideas.

stefanbirkner · 2013-08-21T22:57:09Z

I tried the dontWrap method, but unfortunately its makes the API and documentation harder to understand. Therefore I would propose to do without this method. I don't think that there are many people who need this improvement for their JUnit extensions. Do you know an extension, which uses an additional Exception for framework communication?

stefanbirkner · 2013-08-22T18:46:10Z

I think we should revert 128553f. Whenever you have a test that uses ExpectedException together with assumeXXX or assertXXX, you can but the assume or assert before the thrown.expectXXX call and everything works like expected.

I recommend to add this to ExpectedException's documentation and revert the change. @dsaff How to you think about it?

dsaff · 2013-09-03T22:33:03Z

Works for me, @stefanbirkner. Sorry for the delay in communication.

stefanbirkner · 2013-09-03T23:49:30Z

@dsaff It's ready.

dsaff · 2013-09-16T23:50:55Z

src/main/java/org/junit/rules/ExpectedException.java

- * 	public ExpectedException thrown= ExpectedException.none();
+ * <p>
+ * You can combine any of the presented expect-methods. The test is
+ * successful if all specifictions are met.


Check spelling

dsaff · 2013-09-16T23:56:16Z

Looking good. Added some minor changes to the javadoc.

dsaff · 2013-09-16T23:58:54Z

src/main/java/org/junit/rules/ExpectedException.java

    private String missingExceptionMessage;

    private ExpectedException() {
    }

-    public ExpectedException handleAssertionErrors() {


Actually, it's very unusual for us to remove abruptly a method that was already in a public release of JUnit. We should probably leave these in, deprecated, with no implementation and javadoc about how things have changed.

I restored the methods. They now throw an exception in order to notify the user about the deprecation.

stefanbirkner · 2013-09-18T14:36:05Z

@dsaff I'd like to squash the new commits if everything is fine.

dsaff · 2013-09-18T18:14:12Z

@stefanbirkner, I think it makes more sense to leave them as deprecated no-op methods: people who called them were explicitly requesting the behavior that will now be default, right?

stefanbirkner · 2013-09-18T21:19:08Z

That's right. But people, who use this methods, are testing code that's throwing AssertionErrors or AssumptionViolatedExceptions. Therefore they have to adjust their tests, because the default behaviour of ExpectedException changed, too.

IMHO we have to choose between three alternatives:

Change the methods to deprecated no-op methods: We have useless and irritating methods in ExpectedException's API, but all affected users still have to adjust their tests after upgrading to JUnit 4.12 (see explanation above).
Remove the methods: Update to JUnit 4.12 causes compiler errors and users will be cursing us, because they have no idea what's wrong.
Deprecate methods and let them throw errors: Update to JUnit 4.12 causes failing tests. People still will be cursing us, but we give them a hint about what we've done. Afterwards (~ a year) we can remove the methods, because all the people, which are updating regularly, have already removed calls to the method.

I still prefer alternative 3, because it's a good trade-off between lesser code to maintain and upsetting the users.

dsaff · 2013-10-01T00:34:54Z

Sorry, I'm probably just dense tonight. Given this test:

    @Test
    public void catchIt() {
        thrown.handleAssertionErrors();
        thrown.expect(AssertionError.class);
        throw new AssertionError("the unexpected assertion error");
    }

It works in 4.11, and if handleAssertionErrors is a no-op, it works in 4.12, too, right?

stefanbirkner · 2013-10-01T21:10:23Z

That's true. I was wrong with the first alternative. Nobody has to change his methods, if we use no-op methods. The correct first alternative is.

Change the methods to deprecated no-op methods: We have useless and irritating methods in ExpectedException's API.

This means that we must decide, whether we would like to leave the methods forever or not.

dsaff · 2013-10-04T00:51:33Z

@stefanbirkner, we don't actually have to decide today whether we would like to leave the methods forever.

However, it's generally considered kind to give users at least a revision of deprecation warnings before causing their tests to stop compiling. We should leave them in, deprecated, in this release. If no one complains, we can remove them in the next release.

stefanbirkner · 2013-10-04T20:01:00Z

Done. Should i prepare the commits for merging?

UrsMetz · 2013-10-05T20:41:44Z

Shouldn't we have test cases for the special exception type AssertionError as that Throwable is an edge case in the context of JUnit? There was a bug in 4.11 that when an AssertionError was expected but not thrown the test was not red but green, cf. pull request #583. So I think test covering the case when that exception is expected but not thrown should be included (for AssumptionViolationException there is such an test case). Maybe also the "green" cases (e. g. the expected exceptions are actually thrown) should be included.

stefanbirkner · 2013-10-06T11:38:45Z

I'm not sure whether we need additional tests, because AssumptionViolationException and AssertionError are now handled like any other exception. Changing the AssertionError behaviour in 4.11 was not an accident but an explicit (bad) decision of mine.

UrsMetz · 2013-10-06T13:31:00Z

@stefanbirkner I think we're talking about different changes in 4.11 :-): I'm referring to the bug described in #583 (that also you stumbled across according to your comment in the discussion there :-)).
I understand that viewed from the implementation side (now) AssertionError is not handled differently than any other Throwable but as

AssertionError is still a special case in the context of JUnit tests and
there was a bug that the ExpectedException rule didn't make a test fail when an expected AssertionError was not thrown (ExpectedException doesn't fail when an AssertionError is expected but not thrown #583)
I think we should have at least a test case for the bug ExpectedException doesn't fail when an AssertionError is expected but not thrown #583. I included that test case in ExpectedException doesn't fail when an AssertionError is expected but not thrown #583 but I didn't find it in the version of ExpectedExceptionTest.java in the branch you want to merge.

dsaff · 2013-10-13T16:14:11Z

@UrsMetz, did @stefanbirkner's latest test handle your concern?

UrsMetz · 2013-10-15T05:21:56Z

@dsaff: my concern was handled by @stefanbirkner's last commit.

Describe every expect method with a single test.

Still fixes junit-team#121, but the original fix was superfluous. Added documentation about handling assumes and asserts in conjunction with the ExpectedException rule.

Improve readability and avoid duplicate code.

stefanbirkner · 2013-10-16T21:31:34Z

@dsaff I squashed the commits. Everything should be ready for the merge.

Extend ExpectedException's documentation and fix #687.

dsaff · 2013-10-16T22:33:12Z

Done! Thanks!

Can you make a note at https://github.com/junit-team/junit/wiki/4.12-release-notes

stefanbirkner · 2013-10-16T23:15:41Z

Done.

stefanbirkner mentioned this pull request Aug 17, 2013

Fix for issue #687: handle AssertionErrors and AssumptionViolatedExceptions by default again #711

Closed

dsaff reviewed Aug 20, 2013
View reviewed changes

stefanbirkner closed this Aug 22, 2013

stefanbirkner reopened this Aug 22, 2013

dsaff reviewed Sep 16, 2013
View reviewed changes

Rewrite parts of the documentation.

41f9674

Describe every expect method with a single test.

stefanbirkner added 2 commits October 16, 2013 23:22

Revert changes of 128553f. Fixes junit-team#687.

bb13b31

Still fixes junit-team#121, but the original fix was superfluous. Added documentation about handling assumes and asserts in conjunction with the ExpectedException rule.

Extract isAnyExceptionExpected().

8b35f0c

Improve readability and avoid duplicate code.

dsaff pushed a commit that referenced this pull request Oct 16, 2013

Merge pull request #720 from stefanbirkner/expected-exception

0f623cd

Extend ExpectedException's documentation and fix #687.

dsaff merged commit 0f623cd into junit-team:master Oct 16, 2013

stefanbirkner deleted the expected-exception branch October 16, 2013 23:00

kcooney mentioned this pull request Oct 24, 2018

ExpectedException fails when assumption fails #1566

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Extend ExpectedException's documentation and fix #687. #720

Extend ExpectedException's documentation and fix #687. #720

stefanbirkner commented Aug 17, 2013

dsaff Aug 20, 2013

dsaff commented Aug 20, 2013

stefanbirkner commented Aug 21, 2013

stefanbirkner commented Aug 22, 2013

dsaff commented Sep 3, 2013

stefanbirkner commented Sep 3, 2013

dsaff Sep 16, 2013

dsaff commented Sep 16, 2013

dsaff Sep 16, 2013

stefanbirkner Sep 18, 2013

stefanbirkner commented Sep 18, 2013

dsaff commented Sep 18, 2013

stefanbirkner commented Sep 18, 2013

dsaff commented Oct 1, 2013

stefanbirkner commented Oct 1, 2013

dsaff commented Oct 4, 2013

stefanbirkner commented Oct 4, 2013

UrsMetz commented Oct 5, 2013

stefanbirkner commented Oct 6, 2013

UrsMetz commented Oct 6, 2013

dsaff commented Oct 13, 2013

UrsMetz commented Oct 15, 2013

stefanbirkner commented Oct 16, 2013

dsaff commented Oct 16, 2013

stefanbirkner commented Oct 16, 2013

Extend ExpectedException's documentation and fix #687. #720

Extend ExpectedException's documentation and fix #687. #720

Conversation

stefanbirkner commented Aug 17, 2013

dsaff Aug 20, 2013

Choose a reason for hiding this comment

dsaff commented Aug 20, 2013

stefanbirkner commented Aug 21, 2013

stefanbirkner commented Aug 22, 2013

dsaff commented Sep 3, 2013

stefanbirkner commented Sep 3, 2013

dsaff Sep 16, 2013

Choose a reason for hiding this comment

dsaff commented Sep 16, 2013

dsaff Sep 16, 2013

Choose a reason for hiding this comment

stefanbirkner Sep 18, 2013

Choose a reason for hiding this comment

stefanbirkner commented Sep 18, 2013

dsaff commented Sep 18, 2013

stefanbirkner commented Sep 18, 2013

dsaff commented Oct 1, 2013

stefanbirkner commented Oct 1, 2013

dsaff commented Oct 4, 2013

stefanbirkner commented Oct 4, 2013

UrsMetz commented Oct 5, 2013

stefanbirkner commented Oct 6, 2013

UrsMetz commented Oct 6, 2013

dsaff commented Oct 13, 2013

UrsMetz commented Oct 15, 2013

stefanbirkner commented Oct 16, 2013

dsaff commented Oct 16, 2013

stefanbirkner commented Oct 16, 2013