A JUnit Rule to Conditionally Ignore Tests

Home  >>  JUnit  >>  A JUnit Rule to Conditionally Ignore Tests

A JUnit Rule to Conditionally Ignore Tests

On November 18, 2013, Posted by , In JUnit, By ,, , With 10 Comments

I always believed that using @Ignore to deactivate tests is a bad idea. Except, maybe as one way to put tests that fail intermittently into quarantine to attend to them later (as Martin Fowler describes it here). This bears the danger that the test suite decays as more and more tests keep getting ignored and forgotten. Therefore you should have a policy in place to ensure that tests aren’t quarantined for too long. Well, so I thought until recently when we ran into this:

In a project that Frank and I work on, we ran into an SWT issue described here. On non-Windows platforms, asserting whether an SWT widget has got the input focus does not work with automated tests.

We decided to ignore focus-related tests on non-Windows platforms for now. Though our build server runs on Linux we found it safe enough as both our development environments run on Windows.

In JUnit, assumptions are the means to skip tests that aren’t meaningful under the given condition. Expressed that way, our test would look like this:

public void testFocus() {
  assumeTrue( isRunningOnWindows() );
  // ...

But we didn’t want the test code mingled with conditions if it should be executed at all. The code that decides whether the test is ignored should be separated from the test code itself.

This led us to creating a ConditionalIgnore annotation and a corresponding rule to hook it into the JUnit runtime. The thing is simple and best explained with an example:

public class SomeTest {
  public ConditionalIgnoreRule rule = new ConditionalIgnoreRule();

  @ConditionalIgnore( condition = NotRunningOnWindows.class )
  public void testFocus() {
    // ...

public class NotRunningOnWindows implements IgnoreCondition {
  public boolean isSatisfied() {
    return !System.getProperty( "os.name" ).startsWith( "Windows" );

The ConditionalIgnore annotation requires a ‘condition’ property that points to a class that implements IgnoreContition. At runtime, an instance of the IgnoreCondition implementation is created and its isSatisfied() method decides whether the test is ignored (returns true) or not (returns false). Finally there is an IgnoreConditionRule that hooks the annotations into the JUnit runtime.

If the IgnoreCondition implementation decides to ignore a test case, an AssumptionViolatedException is thrown. Therefore the ConditionalIgnore annotation has the same effect as if an Assume condition would return false. With a slight difference that we consider an advantage: @Before and @After methods are not executed for ignored tests.

The source code of the rule and its related classes can be found here.

The remaining issue with Assume is that it affects the test statistics. If an Assume condition is found to be false, it treats the test as having passed even though it hasn’t run. To overcome that, you’d have to provide your own runner that handles AssumptionViolatedException the way you want.

Even though I just wrote about ignoring tests in length, I am still convinced that tests at best should not be ignored and if so only in exceptional cases.

Rüdiger Herrmann

Rüdiger started writing software more than 20 years ago. From the very beginning he focused on a pragmatic approach to writing and delivering software.

His interests include promoting test driven development and agile methods to deliver clean code that works.

(EMail: rherrmann@codeaffine.com)

Latest posts by Rüdiger Herrmann (see all)

10 Comments so far:

  1. Tomek says:

    Looks like a good example of JUnit rule usage! Thanks for sharing!

    Tomek Kaczanowski

  2. Vijaya says:

    By Using the above sample, if a testcase is ignored, will that appear in Skipped one, if so, how to make sure that test case is ignored and does not appear in Skipped one

    • Rüdiger Herrmann says:


      if you refer to Maven ‘skipped’ tests, then yes, the maven test runner lists ignored tests as skipped. But as I said above, how assumption violations are handled is up to the test runner. Does that answer your question?


  3. Matt Morrissette says:

    The above example can cause an error using the referenced gist on GitHub for the ConditionalIgnoreRule if your class that extends IgnoreCondition is declared inside your test case.

    Please use the gist at:

    • Rüdiger Herrmann says:

      Good catch, Matt. Thank you for this hint. I have also updated the original gist so that readers who don’t follow down to the comments benefit from your enhancement.

  4. Sebastian Millies says:

    Thanks for the post. Your approach does makt the test code cleaner.

    One idea, not tested: With java 8, shouldn’t it be possible to simplify things quite a bit and leave out the IgnoreConditionCreator, passing a lambda directly in @ConditionalIgnore? The interface IgnoreCondition could just trivially extend BooleanSupplier.

  5. Sebastian Millies says:

    Well, I guess I have to take that back because functional interfaces are not allowed as annotation method return types, making it impossible to pass a lambda as an annotation parameter. Too bad.

    • Sebastian Millies says:

      However, it is still possible to have better static type safety and simpler reflection code by requiring IgnoreCondition to be implemented by enum constants. See my fork of your gist at https://gist.github.com/smillies/2ca19e1faa903f08f47e

      • Rüdiger Herrmann says:

        Thanks Sebastian for sharing your idea and pardon the delay, I was on vacation.

        I can’t help but your approach seems to complicate things for clients, or am I missing something? In your example, clients have to specify the enum-class and a string that denotes the enum-value (which might break during rename refactorings) whereas the original approach only requires a class to be specified.

  6. Olegs Klujs says:

    Thanks Herrmann,

    Just what I was searching for.
    Made my day!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>