Question

I have occasionally heard or read about people asserting their interfaces in a unit test. I don’t mean mocking an interface for use in another type’s test, but specifically creating a test to accompany the interface.

Consider this ultra-lame and off-the-cuff example:

public interface IDoSomething
{
   string DoSomething();
}

and the test:

[TestFixture]
public class IDoSomethingTests
{
   [Test]
   public void DoSomething_Should_Return_Value()
   {
        var mock = new Mock<IDoSomething>();
        var actualValue = mock.Expect(m => m.DoSomething()).Returns("value");

        mock.Object.DoSomething();
        mock.Verify(m => DoSomething());
        Assert.AreEqual("value", actualValue);
   }
}

I suppose the idea is to use the test to drive the design of the interface and also to provide guidance for implementors on what’s expected so they can draw good tests of their own.

Is this a common (recommended) practice?

Answer 1

In my opinion, just testing the interface using a mocking framework tests little else than the mocking framework itself. Nothing I would spend time on, personally.

I would say that what should drive the design of the interface is what functionality that is needed. I think it would be hard to identify that using only a mocking framework. By creating a concrete implementation of the interface, what is needed or not will become more obvious.

The way I tend to do it (which I by no means claim is the recommended way, just my way), is to write unit tests on concrete types, and introduce interfaces where needed for dependency injection purposes.

For instance, if the concrete type under test needs access to some data layer, I will create an interface for this data layer, create a mock implementation for the interface (or use a mocking framework), inject the mock implementation and run the tests. In this case the interface serves no purpose than offering an abstraction for the data layer.