A JUnit Rule to Conditionally Ignore Tests

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 {
  @Rule
  public ConditionalIgnoreRule rule = new ConditionalIgnoreRule();

  @Test
  @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.
 

Reference: A JUnit Rule to Conditionally Ignore Tests from our JCG partner Rudiger Herrmann at the Code Affine blog.
Related Whitepaper:

Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code

Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!

To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.

Get it Now!  

Leave a Reply


8 − six =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books