title: Patterns or practices for unit testing methods that call a static method
body: <p>As of late, I have been pondering heavily about the best way to "Mock" a static method that is called from a class that I am trying to test.  Take the following code for example:</p>
  
  <pre><code>using (FileStream fStream = File.Create(@"C:\test.txt"))
  {
      string text = MyUtilities.GetFormattedText("hello world");
      MyUtilities.WriteTextToFile(text, fStream);
  }
  </code></pre>
  
  <p>I understand that this is a rather bad example, but it has three static method calls that are all different slightly. The File.Create function access the file system and I don't own that function.  The MyUtilities.GetFormattedText is a function that I own and it is purely stateless. Finally, the MyUtilities.WriteTextToFile is a function I own and it accesses the file system.</p>
  
  <p>What I have been pondering lately is if this were legacy code, how could I refactor it to make it more unit-testable.  I have heard several arguments that static functions should not be used because they are hard to test.  I disagree with this idea because static functions are useful and I don't think that a useful tool should be discarded just because the test framework that is being used can't handle it very well.</p>
  
  <p>After much searching and deliberation, I have come to the conclusion that there are basically <strong>4 patterns or practices</strong> that can be used in order to make functions that call static functions unit-testable.  These include the following:</p>
  
  <ol>
  <li><b>Don't mock</b> the static function at all and just let the unit test call it.</li>
  <li>Wrap the static method in an instance class that implements an interface with the function that you need on it and then use dependency injection to use it in your class. I'll refer to this as <b>interface dependency injection</b>.</li>
  <li>Use <b>Moles</b> (or TypeMock) to hijack the function call.</li>
  <li>Use dependeny injection for the function. I'll refer to this as <b>function dependency injection</b>.</li>
  </ol>
  
  <p>I've heard quite a lot of discussion about the first three practices, but as I was thinking about solutions to this problem, the forth idea came to me of <strong>function dependency injection</strong>.  This is similar to hiding a static function behind an interface, but without actually needing to create an interface and wrapper class.  An example of this would be the following:</p>
  
  <pre><code>public class MyInstanceClass
  {
      private Action&lt;string, FileStream&gt; writeFunction = delegate { };
  
      public MyInstanceClass(Action&lt;string, FileStream&gt; functionDependency)
      {
          writeFunction = functionDependency;
      }
  
      public void DoSomething2()
      {
          using (FileStream fStream = File.Create(@"C:\test.txt"))
          {
              string text = MyUtilities.GetFormattedText("hello world");
              writeFunction(text, fStream);
          }
      }
  }
  </code></pre>
  
  <p>Sometimes, creating an interface and wrapper class for a static function call can be cumbersome and it can pollute your solution with a lot of small classes whose sole purpose is to call a static function.  I am all for writing code that is easily testable, but this practice seems to be a workaround for a bad testing framework.</p>
  
  <p>As I was thinking about these different solutions, I came to an understanding that all of the 4 practices mentioned above can be applied in different situations. Here is what I am thinking is the <strong>correct cicumstances to apply the above practices</strong>:</p>
  
  <ol>
  <li><b>Don't mock</b> the static function if it is purely stateless and does not access system resources (such as the filesystem or a database). Of course, the argument can be made that if system resources are being accessed then this introduces state into the static function anyway.</li>
  <li>Use <b>interface dependency injection</b> when there are several static functions that you are using that can all logically be added to a single interface. The key here is that there are several static functions being used.  I think that in most cases this will not be the case.  There will probably only be one or two static functions being called in a function.</li>
  <li>Use <b>Moles</b> when you are mocking up external libraries such as UI libraries or database libraries (such as linq to sql).  My opinion is that if Moles (or TypeMock) is used to hijack the CLR in order to mock your own code, then this is an indicator that some refactoring needs to be done to decouple the objects.</li>
  <li>Use <b>function dependency injection</b> when there is a small number of static function calls in the code that is being tested.  This is the pattern that I am leaning towards in most cases in order to test functions that are calling static functions in my own utility classes.</li>
  </ol>
  
  <p>These are my thoughts, but I would really appreciate some feedback on this.  What is the best way to test code where an external static function is being called?</p>