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 ¹. More precisely if you assume a signature that looks like
 
 
 
 
 
 
 
 

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

a test might verify the following²:

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 rule³. 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. ↩