Test Driving Interface Design 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));
    }
}
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.