How to deal with interface overuse in TDD?

Asked 2011-03-23T21:08:33.327

I've noticed that when I'm doing TDD it often leads to a very large amount of interfaces. For classes that have dependencies, they are injected through the constructor in the usual manner:

public class SomeClass
{
    public SomeClass(IDependencyA first, IDependency second)
    {
        // ...
    }
}

The result is that almost every class will implement an interface.

Yes, the code will be decoupled and can be tested very easily in isolation, but there will also be extra levels of indirection that just makes me feel a little...uneasy. Something doesn't feel right.

Can anyone share other approaches that doesn't involve such heavy use of interfaces?

How are the rest of you guys doing?

c# unit-testing interface tdd

Edit Report

2 Answers

Don't use interfaces! Most mocking frameworks can mock concrete classes.

answered 2011-03-23T21:12:28.497

That's the drawback of mock based testing approaches. This is as much a test boundary discussion as it is about mocking. By having a 1:1 ratio of test cases to domain classes your test boundary is very small. A result of a small test boundary is a proliferation of interfaces and tests that depend on them. Refactoring becomes more difficult due to the number of interactions you are mocking and stubbing out. By testing clusters of classes with a single test, refactoring becomes easier and you use fewer interfaces. Beware, however that you can test too many classes at once. The more complexity your classes have, the more code paths you need to test. This can lead to a combinatorial explosion and you can't possibly test them all. Listen to the code and tests, they're telling you something about your code. If you see the complexity increasing, it's probably a good time to introduce a new Test Case and Interface/Implementation and mock it out in your original.

answered 2011-03-24T00:46:34.923

How to deal with interface overuse in TDD?

2 Answers

Your Answer