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.

Sign up for GitHub

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

Tests expecting AssumptionViolatedException should be marked as passed, not skipped #1291

Merged
merged 9 commits into from
Feb 14, 2017
Merged

Tests expecting AssumptionViolatedException should be marked as passed, not skipped #1291

Show file tree
Hide file tree
Changes from 4 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
c71c878
Fix #1290
alb-i986 May 12, 2016
939ade5
add unit test
alb-i986 May 13, 2016
6def963
fix unit test
alb-i986 May 13, 2016
e6aee89
fix style: rm double return line
alb-i986 May 13, 2016
4a79e75
add integration test
alb-i986 May 13, 2016
ca669b6
Merge branch 'master' into fix-1290
alb-i986 May 18, 2016
aa582cb
addressing review comments
alb-i986 May 19, 2016
95800b6
adressing review comments
alb-i986 Jan 23, 2017
0ea179f
Merge branch 'master' into fix-1290
alb-i986 Jan 23, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion src/main/java/org/junit/internal/runners/statements/ExpectException.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,9 @@ public void evaluate() throws Exception {
next.evaluate();
complete = true;
} catch (AssumptionViolatedException e) {
throw e;
if (!expected.isAssignableFrom(e.getClass())) {
throw e;
}
} catch (Throwable e) {
if (!expected.isAssignableFrom(e.getClass())) {
String message = "Unexpected exception, expected<"
Expand Down
2 changes: 2 additions & 0 deletions src/test/java/org/junit/internal/AllInternalTests.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@
import org.junit.internal.matchers.StacktracePrintingMatcherTest;
import org.junit.internal.matchers.ThrowableCauseMatcherTest;
import org.junit.internal.runners.ErrorReportingRunnerTest;
import org.junit.internal.runners.statements.ExpectExceptionTest;
import org.junit.internal.runners.statements.FailOnTimeoutTest;
import org.junit.runner.RunWith;
import org.junit.runners.Suite;
Expand All @@ -13,6 +14,7 @@
@SuiteClasses({
AnnotatedBuilderTest.class,
ErrorReportingRunnerTest.class,
ExpectExceptionTest.class,
FailOnTimeoutTest.class,
MethodSorterTest.class,
StacktracePrintingMatcherTest.class,
Expand Down
29 changes: 29 additions & 0 deletions src/test/java/org/junit/internal/runners/statements/ExpectExceptionTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
package org.junit.internal.runners.statements;

import org.junit.Test;
import org.junit.internal.AssumptionViolatedException;
import org.junit.runners.model.Statement;

import static org.junit.Assert.*;

public class ExpectExceptionTest {

@Test
public void givenWeAreExpectingAssumptionViolatedExceptionAndAStatementThrowingAssumptionViolatedException() {
Copy link
Member

Choose a reason for hiding this comment

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

I like descriptive method names but this is a bit long. How about:

whenExpectingAssumptionViolatedExceptionStatementsThrowingItShouldPass

Copy link
Contributor Author

Choose a reason for hiding this comment

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

agreed

ExpectException sut = new ExpectException(new StatementThrowingAssumptionViolatedException(), AssumptionViolatedException.class);
Copy link
Member

Choose a reason for hiding this comment

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

Can we instead test this in org.junit.tests.running.methods.ExpectedTest in the same way we test the expected attributes? We get a bit more confidence if when test features like this by writing tests that run specific tests and verify JUnit gives the proper result for those test runs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure I'll do that. But I also would like to keep this unit test, which is really a unit test, small.

Copy link
Member

Choose a reason for hiding this comment

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

Sure, having both kinds of tests is fine. The integration test is necessary to verify the bug is fixed; the unit test verifies the contract of the ExpectException class.

If we keep this test class, please have the class Javadoc say where the integration tests are (using@link)

A few suggested changes:

  1. Could you update this test to use https://github.com/junit-team/junit4/blob/master/src/main/java/org/junit/internal/runners/statements/Fail.java ? That way, you can see what exception the Statement is throwing by looking at the test method.
  2. Extract a local variable for the expression you pass to the ExpectException constructor and call that variable delegate.
  3. I don't think we use sut as a variable name very often. If we don't, I suggest naming it expectException so future readers wont be confused by the name.

Copy link
Member

Choose a reason for hiding this comment

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

Also, if you are adding unit tests, please add a test that makes sure that tests that expect AssumptionViolatedException but do not throw it should fail

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could you update this test to use https://github.com/junit-team/junit4/blob/master/src/main/java/org/junit/internal/runners/statements/Fail.java ?

done

Extract a local variable for the expression you pass to the ExpectException constructor and call that variable delegate

Done, but I gave it a more meaningful name, although a bit longer: statementThrowingAssumptionViolatedException

I don't think we use sut as a variable name very often. If we don't, I suggest naming it expectException so future readers wont be confused by the name

Done but I would suggest to consider adopting it.
I think I took it from xunitpatterns, see e.g. http://xunitpatterns.com/Test%20Stub.html (scroll to "Motivating Example"):

   public void testDisplayCurrentTime_AtMidnight() {
      // fixture setup
      TimeDisplay sut = new TimeDisplay();
      // exercise sut
      String result = sut.getCurrentTimeAsHtmlFragment();
      // verify direct output
      String expectedTimeString = "<span class=\"tinyBoldText\">Midnight</span>";
      assertEquals( expectedTimeString, result);
   }

I find it a great name as it clearly stands out among the many variables (the DOCs, following Meszaros's terminology) which may be defined in a unit test.

It also makes it extremely easy to distinguish the "when" step: it's the one (and only, in theory) of the form sut.method(inputs). In the example above, sut.getCurrentTimeAsHtmlFragment();

Also, if you are adding unit tests, please add a test that makes sure that tests that expect AssumptionViolatedException but do not throw it should fail

Done. I've also added a couple more scenarios:

  • scenario where the given statement passes
  • scenario where the statement throws subclass of AssumptionViolatedEx


try {
sut.evaluate();
// then no exception should be thrown
} catch (Throwable e) {
fail("should not throw anything, but was thrown: " + e);
Copy link
Member

@kcooney kcooney May 14, 2016 •
edited
Loading

Choose a reason for hiding this comment

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

No need to catch unexpected exceptions; if evaluate throws an exception then the test would fail.

Edit: Woops! I see why you need to do an explicit catch; without your fix this test would not fail because of the assumption failure exception being thrown.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ya right! Tricky uh? :) Testing JUnit with JUnit is tricky itself

}
}

private static class StatementThrowingAssumptionViolatedException extends Statement {
@Override
public void evaluate() throws Throwable {
throw new AssumptionViolatedException("expected");
}
}
}