# Test Driving Interface Design [closed]

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]
{
var iPairSessionType = typeof(IPairSession);
var insertMethod = iPairSessionType.GetMethod("Insert");
Assert.That(insertMethod.IsDefined(typeof(OperationContractAttribute), true));
}
}

-

## closed as off-topic by Jamal♦Feb 21 '14 at 18:53

If this question can be reworded to fit the rules in the help center, please edit the question.

The things you check in your tests are already checked by the compiler. So these tests add no value. Tests are code too, and they need maintenance. These test cases are just liabilites and not assets. For greenfield TDD take a look at growing-object-oriented-software.com Basic Idea is that you should have some other component that uses this interface. You should test in the unit tests of this component the assumptions about this code. –  abuzittin gillifirca Jan 21 '13 at 9:52
This question appears to be off-topic because it is primarily a design review. –  Jamal Feb 21 '14 at 18:53

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.

-

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.

-

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.

-