Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

How can I avoid code duplication in unit tests?

Using Java and JUnit suppose I have something like this:

public interface Arithmetic<T> {
    public T add(T a, T b);
    public T sub(T a, T b);
}

public void IntegerArithmetic<Integer> {
    //
}

public void DoubleArithmetic<Double> {
    //
}

And the test class:

public class TestArith {

private Arithmetic<Integer> arith;

@Before
public void init() {
    Arithmetic<Integer> arith = new IntegerArithmetic();
    Integer term1 = 4;
    Integer term2 = 3;
}

@Test
public void testAdd() {
     assertEquals(7, arith.add(term1, term2));
}

@Test
public void testAdd() {
     assertEquals(1, arith.sub(term1, term2));
}
}

The problem is that the test class for the DoubleArithmetic class should look exactly the same; the only difference is in @Before init() where the initialization of the concrete type is done. How can this code duplication be avoided?

share|improve this question
    
I think this question is a much better fit for stackoverflow. –  dasblinkenlight Aug 10 '12 at 14:52
1  
stackoverflow.com/questions/6453235/… –  jk. Aug 10 '12 at 15:19
1  
stackoverflow.com/questions/129693/… –  jk. Aug 10 '12 at 15:21
1  
@dasblinkenlight Not necessarily, if we're talking about designing the unit test class. –  rmaruszewski Aug 10 '12 at 15:23
    
It should be noted that doubles will not necessarily be exactly equal, so you may have differences due to that. The assertEquals(double, double) method is deprecated, after all (use the one with an epsilon instead). –  Clockwork-Muse Aug 10 '12 at 18:21

2 Answers 2

up vote 4 down vote accepted

Declare class TestArith as abstract. Then create two classes, TestIntegerArith and TestDoubleArith extending TestArith. In the TestArith create an abstract method getArithmetic, which returns an instance of Arithmetic. Then change the tests to get Arithmetic instance by calling getArithmetic.

So it would look like this:

public abstract class TestArith<T> {
  protected abstract Arithmetic<T> getArithmetic();

  @Test
  public void testAdd() {
      assertEquals(7, getArithmetic().add(term1, term2));
  }
}
share|improve this answer

This is not always so.

Obviously, tests for 10 / 4 or 1 << 31 * 5 will give different results in IntegerArithmetic and DoubleArithmetic.

If there's a large subset where IntegerArithmetic and DoubleArithmetic should act the same, try instantiating a class based on a common interface, e.g. Arithmetic<java.lang.Number>.

Let me elaborate a bit.

There are two places where code duplication may arise: the initialization, which only differs by the class being tested, and the test cases.

Common tests can go into a common case which can be subclassed, and each subclass's .setUp() will instantiate its own concrete instance of Arithmetic to test.

Class-specific tests get their own test cases.

Initialization code can be de-duplicated by using a parametrized base class from which concrete instances of TestCase will arise, as @Skillwired proposes.

share|improve this answer
    
The expected value may differ, but the logic of the code is identical; the code is identical. Regarding the second idea, that's the problem: both classes need to be tested so both need to be instantiated for this. –  m3th0dman Aug 10 '12 at 15:08
    
See the updated answer. –  9000 Aug 10 '12 at 15:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.