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
  }
}

Answer 3

I don't think this is best practice.

The simple truth is that an interface is nothing more than a contract that a method is implemented. 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.

If you really want to be in control of your method implementation, you have the option of:

• Implementing it as a method in an abstract class, and inherit from that. You will still need to inherit it into a concrete class, but you are sure that unless it is explicitly overriden that method will do that correct thing.
• In .NET 3.5/C# 3.0, implementing the method as an extension method referencing to the Interface

Example:

public static ReturnType MethodName (this IMyinterface myImplementation, SomeObject someParameter)
{
    //method body goes here
}

Any implementation properly referencing to that extension method will emit precisely that extension method so you only need to test it once.

Answer 4

@Emperor XLII

I like the sound of combinatorial tests in MbUnit, I've tried the abstract base class interface test technique with NUnit, and although it does work, you'd need to have a seperate test fixture for every interface a class implements (since in C# there is no multiple inheritance - although inner classes can be used, which is pretty cool). In reality this is fine, maybe even advantageous because it groups your tests for the implementing class by interface. But it would be good if the framework could be smarter. If I could use an attribute to mark a class as an 'official' test class for an interface, and the framework would search the assembly under test for all classes that implement the interface, and run those tests on it.

That would be cool.

Answer 5

How about a hierarchy of [TestFixture]s classes? Put the common test code in the base test class and inherit it into child test classes..

Answer 6

When testing an interface or base class contract, I prefer to let the test framework automatically take care of finding all of the implementers. This lets you concentrate on the interface under test and be reasonably sure that all implementations will be tested, without having to do a lot of manual implementation.

• For xUnit.net, I created a Type Resolver library to search for all implementations of a particular type (the xUnit.net extensions are just a thin wrapper over the Type Resolver functionality, so it can be adapted for use in other frameworks).
• In MbUnit, you can use a CombinatorialTest with UsingImplementations attributes on the parameters.
• For other frameworks, the base class pattern Spoike mentioned can be useful.

Beyond testing the basics of the interface, you should also test that each individual implementation follows its particular requirements.

Answer 7

I don't use NUnit but I have tested C++ interfaces. I would first test a TestFoo class which is a basic implementation of it to make sure the generic stuff works. Then you just need to test the stuff that is unique to each interface.