Side benefits of testablity
time to read 2 min | 331 words

A while ago I needed to test the output of a class that wrote data to a file. I didn't want to start reading/ writing files in my tests, so I created the following interface:

public interface IOutputFactory
{
  TextWriter Create(string name);
}

This was easy to mock, and I could get the output back very easily. I didn't gave it much thought afterward, except to cuckle a bit at this interface's purpose. The implementation was simple:

return File.CreateText(name);

Then, I got a new requirement from the customer: When I finish writing to a file, I should rename it using a pre-defined pattern. I really have no idea how I would have found all the file I/O operations in this application, but using the approach above, I created a RenamingTextWriter, which would rename the output file when it is closed. That change was a matter of minutes, as was the change to add application wide enconding to the file.

In Working With Legacy Code, Michael talks quite a bit about the seams of the system, where you can insert your mocks and start testing. What I have found is that those seams are very useful for adding functionality, the above case is fairly simple, but I'm using the same approach quite a bit all over the place.

Tweet Share Share 0 comments
Tags: