NUnit - How to test all classes that implement a particular interface

Question

If I have interface IFoo, and have several classes that implement it, what is the best/most elegant/cleverest way to test all those classes against the interface?

I'd like to reduce test code duplication, but still 'stay true' to the principles of Unit testing.

What would you consider best practice? I'm using NUnit, but I suppose examples from any Unit testing framework would be valid

Answer 1

If you have classes implement any one interface then they all need to implement the methods in that interface. In order to test these classes you need to create a unit test class for each of the classes.

Lets go with a smarter route instead; if your goal is to avoid code and test code duplication you might want to create an abstract class instead that handles the recurring code.

E.g. you have the following interface:

public interface IFoo {      public void CommonCode();      public void SpecificCode();  } 

You might want to create an abstract class:

public abstract class AbstractFoo : IFoo {      public void CommonCode() {           SpecificCode();     }      public abstract void SpecificCode();  } 

Testing that is easy; implement the abstract class in the test class either as an inner class:

[TestFixture] public void TestClass {      private class TestFoo : AbstractFoo {         boolean hasCalledSpecificCode = false;         public void SpecificCode() {             hasCalledSpecificCode = true;         }     }      [Test]     public void testCommonCallsSpecificCode() {         TestFoo fooFighter = new TestFoo();         fooFighter.CommonCode();         Assert.That(fooFighter.hasCalledSpecificCode, Is.True());     } } 

...or let the test class extend the abstract class itself if that fits your fancy.

[TestFixture] public void TestClass : AbstractFoo {      boolean hasCalledSpecificCode;     public void specificCode() {         hasCalledSpecificCode = true;     }      [Test]     public void testCommonCallsSpecificCode() {         AbstractFoo fooFighter = this;         hasCalledSpecificCode = false;         fooFighter.CommonCode();         Assert.That(fooFighter.hasCalledSpecificCode, Is.True());     }          } 

Having an abstract class take care of common code that an interface implies gives a much cleaner code design.

I hope this makes sense to you.

---

As a side note, this is a common design pattern called the Template Method pattern. In the above example, the template method is the CommonCode method and SpecificCode is called a stub or a hook. The idea is that anyone can extend behavior without the need to know the behind the scenes stuff.

A lot of frameworks rely on this behavioral pattern, e.g. ASP.NET where you have to implement the hooks in a page or a user controls such as the generated Page_Load method which is called by the Load event, the template method calls the hooks behind the scenes. There are a lot more examples of this. Basically anything that you have to implement that is using the words "load", "init", or "render" is called by a template method.

Answer 2

I disagree with Jon Limjap when he says,

It is not a contract on either a.) how the method should be implemented and b.) what that method should be doing exactly (it only guarantees the return type), the two reasons that I glean would be your motive in wanting this kind of test.

There could be many parts of the contract not specified in the return type. A language-agnostic example:

public interface List {    // adds o and returns the list   public List add(Object o);    // removed the first occurrence of o and returns the list   public List remove(Object o);  } 

Your unit tests on LinkedList, ArrayList, CircularlyLinkedList, and all the others should test not only that the lists themselves are returned, but also that they have been properly modified.

There was an earlier question on design-by-contract, which can help point you in the right direction on one way of DRYing up these tests.

If you don't want the overhead of contracts, I recommend test rigs, along the lines of what Spoike recommended:

abstract class BaseListTest {    abstract public List newListInstance();    public void testAddToList() {     // do some adding tests   }    public void testRemoveFromList() {     // do some removing tests   }  }  class ArrayListTest < BaseListTest {   List newListInstance() { new ArrayList(); }    public void arrayListSpecificTest1() {     // test something about ArrayLists beyond the List requirements   } }