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.