title: Are Using Interfaces Soley to Facilitate Stubing and Mocking in Unit Tests Now Obsolete?
body: <p>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 to mock in Moq or Rhino Mocks, now no longer is the case.</p>
  
  <p>I've always had some aversion with the idea of using an interface merely to be able to allow for mocking, when otherwise just the concrete class would exist. I'm not alone in this view (see <a href="https://stackoverflow.com/questions/90851/is-it-just-me-or-are-interfaces-overused">here</a>, <a href="https://stackoverflow.com/questions/956011/useless-interfaces">here</a>, and <a href="https://stackoverflow.com/questions/2659366/java-interfaces-methodology-should-every-class-implement-an-interface">here</a>). In the later it's implied that 'modern' mocking frameworks no longer need interfaces for testing or dependency injection.</p>
  
  <p>However, while I can't speak for TypeMock Isolator, I can say that using Mocks in Microsoft Moles is extremely slow. Having code like the following in unit tests makes the speed of the test too slow to be used often:</p>
  
  <pre><code>MFile.ReadAllLinesString = (s) =&gt; csvDataCorrectlyFormatted;
  MDirectoryInfo.AllInstances.GetFilesString = (di,fi) =&gt; fileInfoArray;
  MFileInfo.AllInstances.NameGet = (fi) =&gt; "Doesn't Matter";
  </code></pre>
  
  <p>I'm sure that if the method being tested was programmed to an interface or abstract base class (so that the file system code could be abstracted away in a wrapper of sorts) that using frameworks like Moq for stubbing or mocking would end up being faster. But then we are back to the situation of having added production code complexity for basically the ability to unit test.</p>
  
  <p>I'm leaning to the opinion that Isolator and Moles should only be used when one can't mock with traditional mocking frameworks. Yet, I still struggle with notion of having added production code complexity for the sake of testing. </p>
  
  <p>I'm curious what the rest of the community thinks.</p>
  
  <p><strong>UPDATE 10/06/10:</strong> By saying I struggle with the notion of having added production code complexity for the the sake of testing, I'm referring to the adding an interface (or abstract class even) when otherwise one isn't needed, such as when making the concrete class non-sealed and methods virtual would do. The latter still allows seams for testing. Even if later one finds the need to use an interface for multiple implementations, couldn't they extract it from the class? But unless that need arises, why not follow <a href="http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it" rel="nofollow noreferrer">YAGNI</a>. </p>
  
  <p>I'm all for the SOLID principles where they make the architecture of a program easier to maintain. I don't think these principles need to be followed religiously in every case. I think the mantra, "It always depends", comes into play many times. Otherwise, one is left with every concrete type having an interface or abstract base class, even when there will be only one implementation.</p>
  
  <p>Lastly, I'm not saying that because Isolator and Moles allows one to get around isolation limitations in dynamic-proxy-based frameworks that one shouldn't still design architecture to be maintainable. In many cases, the SOLID principles are what is best, and thus Isolator or Moles wouldn't be needed. It's the cases where the interface is used solely for testing that I am questioning. I'm bringing up another side point about speed too. If one chooses to use Isolator and Moles it appears to bring a speed penalty. So I certainly don't think that they make dynamic-proxy-based frameworks obsolete.</p>