Are Using Interfaces Soley to Facilitate Stubing and Mocking in Unit Tests Now Obsolete?

Question

In .NET, TypeMock Isolator and Microsoft Moles allow one to isolate any class, property, or method - be it sealed, static, protected or non-virtual. So what was impossible t

Answer 1

But then we are back to the situation of having added production code complexity for basically the ability to unit test.

But that's not the reason you do it. You do it because otherwise the code has a hard dependency to an external element. Like a very simple specific implementation of a mail sender.

You isolate the external functionality behind simple contracts, that makes the rest of your code simpler / not more complex. You very clearly see the dependencies the code has, instead of those being hidden in the internals of the code.

You now have a simple mechanism to change those dependencies. There is less resistance when you end up needing to modify those contracts, that when the code is all mixed up in a chatty conversation in the internals of the class.

This is something that's hard to explain in the context of a simple stackoverflow question, specially as it usually takes a very long time for good design concepts to really sink in (if they do ...). I suggest reading about SOLID here.

Replacing like that with TypeMock has its place. To test legacy code that's not properly design, and maybe a handful other scenarios.