Sometimes you want to test several implementations of an Interface that give exactly the same results but with different performance characteristics, for example. Since they are supposed to work the same way you want to use the same tests on each of the implementations to confirm that.

You could make copies of the tests for each class and manually make sure they are the same but it's a maintenance nightmare. We ran into this problem with the AudioMan project and here was our first solution, using the Java List collection as an example. Vector and ArrayList implement the List Interface.

public class ListTest extends TestCase
{
  List list = null;

  public void testExample2()
  {
    this.listTest.testExample2();
  }
}

All of the test implementations are in ListTest. To test the Vector implementation of the List Interface, make functions of the same names in VectorTest that call the corresponding test in ListTest.

This is better than copying the tests because the implementations are only in one class. But as you add new tests to ListTest you have to remember to add the respective calls to the new test to VectorTest and ArrayListTest too. It's better than keeping copies of whole tests but there's still a maintenance problem with this solution. So I was thinking about it this morning and I came up with something else:

public abstract class ListTest extends TestCase
{
  List list = null;

public class ArrayListTest extends ListTest
{
  protected List getList()
  {
    return new ArrayList();
  }
}

With this solution, the test code is still only in one spot: the interface test class ListTest. Then each of the implementing class' test classes subclasses ListTest instead of TestCase and implements the abstract getList() method returning its own implementation of the List Interface, in this case Vector and ArrayList.

All of the test methods are are inherited from ListTest, so VectorTest and ArrayListTest can be executed with JUnit. ListTest can't be run as a test because it is an abstract class.

So there we have it. No more maintenance problems and it's dead easy to add a new implementation's test class.

Update Sunday 12:50pm Andrew suggested I make the ListTest class abstract. I like the idea so I've changed my post. We don't run into that filtering problem with Ant because we put our tests into classifications and only run tests ending with TestA with Ant, but for other projects using the test class names to filter is a good idea.