Running JUnit Tests Repeatedly Without Loops

Recently I came across a problem where I had to write tests for a method that calculates randomly distributed values within a certain range of possibilities 1. More precisely if you assume a signature that looks like

interface RandomRangeValueCalculator {
  long calculateRangeValue( long center, long radius );
}

a test might verify the following2:

public class RandomRangeValueCalculatorImplTest {

  @Test
  public void testCalculateRangeValue() {
    long center = [...];
    long radius = [...];
    RangeValueCalculator calculator = [...];
    
    long actual = calculator.calculateRangeValue( center, radius );

    assertTrue( center + radius >= actual );
    assertTrue( center - radius <= actual );
  }
}

However calculating range values for the same center and radius multiple times will return different results (at least most of the time). Therefore the solution seemed somewhat brittle in a sense that a poor implementation might easily produce intermittent failures. On the other hand I did not want to descend into the depths of actually messuring the value distribution. The latter (random, gaussian or the like) was provided by a collaborator and its proper usage was already confirmed by additional tests.

It occurred to me that a more pragmatic solution could be to actually run the test above automatically over and over again to make it more ‘significant’. Of course the easiest way to achieve this would be to put the test’s content into a loop and go on living.

But for a start it looked somewhat wrong having the asserts within a loop and mixing two aspects into one test run. And even more important the covered problem domain required more tests of the kind. So given the intent of reducing redundancy I remembered my post about JUnit-Rules and implemented a simple repeat rule3. With this rule in place the test above could be gently amended to:

public class RandomRangeValueCalculatorImplTest {

  @Rule
  public RepeatRule repeatRule = new RepeatRule();

  @Test
  @Repeat( times = 10000 )
  public void testCalculateRangeValue() {
    long center = [...];
    long radius = [...];
    RangeValueCalculator calculator = [...];
    
    long actual= calculator.calculateRangeValue( center, radius );

    assertTrue( center + radius >= actual );
    assertTrue( center - radius <= actual );
  }
}

I think it is quite easy to understand that the testCalculateRangeValue method will be executed 10000 times while running the test case. The following snippet shows the implementation of the RepeatRule, which is straight forward:

public class RepeatRule implements TestRule {
  
  @Retention( RetentionPolicy.RUNTIME )
  @Target( {
    java.lang.annotation.ElementType.METHOD
  } )
  public @interface Repeat {
    public abstract int times();
  }

  private static class RepeatStatement extends Statement {

    private final int times;
    private final Statement statement;

    private RepeatStatement( int times, Statement statement ) {
      this.times = times;
      this.statement = statement;
    }

    @Override
    public void evaluate() throws Throwable {
      for( int i = 0; i < times; i++ ) {
        statement.evaluate();
      }
    }
  }

  @Override
  public Statement apply(
    Statement statement, Description description )
  {
    Statement result = statement;
    Repeat repeat = description.getAnnotation( Repeat.class );
    if( repeat != null ) {
      int times = repeat.times();
      result = new RepeatStatement( times, statement );
    }
    return result;
  }
}

So far the RepeatRule serves it purpose and the system functionalities based on the mentioned implementation is working like a charm. Nevertheless sometimes someone misses the forest for the trees and so I thought it might be a good idea to share this solution to see what other people come up with.


  1. Actually this was only one part of the problem domain but I consider it as a sufficient motivation for this post.
  2. Formalistically spoken: f(n,m)∈{e|e≥n-m∧e≤n+m}, for all e,n,m ∈ ℕ
  3. A short google search only came up with a similar solution available in Spring, which was not available in my set of libraries.
Follow me

Frank Appel

Frank is a stalwart of agile methods and test driven development in particular. He understands software development as a craftsmanship based on a well-balanced mix of knowledge and the experience of the daily work.

fappel@codeaffine.com
Follow me

Latest posts by Frank Appel (see all)

Tags: , , ,

6 Responses to “Running JUnit Tests Repeatedly Without Loops”

  • Walid says:

    it’s awesome article, thank you. But your button Google+ doesn’t work somehow.

    Regards
    Walid

  • Arnold says:

    Generating random numbers is a separate concern from doing something with them so it might be a good idea for any implementation of RandomRangeValueCalculator to take a dependency for an implementation of a random value generator.

    This would allow you to pass in a mock random value generator that generates a repeatable series of values allowing you to test the specific boundary cases you are interested in, making your tests precisely predictable and repeatable.

    • Frank Appel says:

      Arnold, I completely agree with your thorough explanation and that is what I meant by the short sentence ‘The latter [...] was provided by a collaborator and its proper usage was already confirmed by additional tests’. So you caught the somewhat weak point in my motivation ;-)

      However working with mocks I consider it desirable to also have kind of integration tests with real collaborator implementations (if possible with reasonable effort). I have observed that “corner cases” might change over time unreflected by tests with mocks. Using mocks reminds me of crash test dummies for cars, where the car manufacturers at some point realized, that they were building very save cars for the dummies – but not for human beings… So mocks are very helpful but they are not the real thing.

      With problems like the given example in the post running tests repeatedly might be a simple way to achieve such ‘real world’ test scenarios.

  • Colin Kershaw says:

    You mention a similar construct available in Spring, but you link generally to the Spring Source site rather than their particular solution. My quick Google search isn’t netting me results – what are you searching exactly to find the Spring solution? Thanks in advance!


Leave a Reply