Test Driving Interface Design

Question

I have been doing TDD since I have started my first job out of university (about 5 months ago), most of which is working with legacy code. I started a personal project today and thought I would TDD it. I don't have much "green field" dev experience so I am unsure if this is the correct way of driving interface design. I am testing the interface has the expected methods, is a service contract etc... I get the feeling this is too much?

The code is shown below:

[TestFixture]
public class IPairSessionTests
{
    [TestCase]
    public void Then_IPairSession_is_a_service_contract()
    {
       var iPairSessionType = typeof(IPairSession);
       Assert.That(iPairSessionType.IsDefined(typeof(ServiceContractAttribute),true));

    }
    [TestCase]
    public void Then_IPairSession_has_Insert_Method()
    {
        var iPairSessionType = typeof(IPairSession);
        Assert.That(iPairSessionType.GetMethod("Insert"), Is.Not.Null);
    }

    [TestCase]
    public void Then_IPairsSession_Insert_is_operation_contract()
    {
        var iPairSessionType = typeof(IPairSession);
        var insertMethod = iPairSessionType.GetMethod("Insert");
        Assert.That(insertMethod.IsDefined(typeof(OperationContractAttribute), true));
    }
}

Answer 1

Yes, it is too much. Testing that methods exist on a contract is both overkill and high-maintenance. If you decide to change a method name, it breaks tests, and the test breakage doesn't tell you something useful. Ask yourself what value you are getting out of this test.

I tend to test interfaces into existence by TDD'ing the classes that use them. I don't think that more is useful.

Answer 2

I think in TDD the interface itself is not the first step (Except it is somehow already given). You create your test and step by step a concrete class. While going through this process you might refactor or optimize you API. Extracting the interface class do make your implementation interchangeable is the last step.

Thinking about the interface in first instance might unnecessarily restrict you.

Answer 3

I'm not too familiar with the C#/.NET world but I guess there are existing tools which do this for you. They might contain more advanced tests, like checking return types, ignoring compatible changes (for example, changing a MySubType parameter to MyType where MySubType extends MyType).

The following Stack Overflow question might be a good start: Tool to verify compatibility of a public APIs

---

If the clients of the interface and the interface are used only inside the same application (therefore, you can modify both and the compiler checks it) these kind of tests seems unnecessary.