Are single implementer interfaces for unit testing an antipattern?

Question

In regards to unit testing, I was taught that production code shouldn't have test-related code in it.

Well, I feel like I'm breaking that rule every time I try to unit test.

I have a class internal to my assembly, Xyzzy. I want to dependency inject it into another class and then stub it so I can test that the other class in isolation, so I make an interface, IXyzzy. Oops, now I have code in production that's really only there for test. Even worse, I've kind of gone against what interface is (describes what an implementer can do, not what it is). Xyzzy's public interface and IXyzzy are exactly the same and no one else (except the stubs) implements IXyzzy.

That seems like a bad thing to me.

I could create an abstract base class or make all the public methods I want to test on Xyzzy Overridable/virtual, but that feels wrong too since Xyzzy isn't designed for inheritance and from a YAGNI perspective, won't ever be inherited from.

Is creating single-implementer interfaces solely for the purpose of testing an anti-pattern? Are there better alternatives?

Answer 1

Yes, it is an anti-pattern. A pattern would be "a solution to a common problem in a certain context". But in this case, what we have is a work-around, not a solution.

The problem in question is the need to isolate a unit to be tested from (some of) its dependencies, so that the implementation of those dependencies doesn't have to be considered when writing the unit tests. The general and true solution to this problem is called "mocking", where the test writer can specify whatever behavior is needed from the mocked dependencies.

In contrast, forcing the developer to create unnecessary separate interfaces, or declare methods as virtual, is only a work-around for the technical inability to cleanly isolate a unit from others.

For .NET, there are several mocking tools that provide this isolation ability, namely TypeMock Isolator, JustMock, and MS Fakes. Other languages/platforms (including Java, Ruby, and Python) have their own tools of similar expressive power.