Are you mocking me?

Let’s suppose that you’re starting a new application. Big. Little. Medium. Doesn’t matter. Just how much do you want to be able to test? What kinds of things are really important to you?

The good news is that you’re thinking about TDD from the get go, and you’re really interested in the architecture of the application. There’s a lot of the .NET framework that I have no problem mocking away. When I’m working with Entity Framework, I don’t even blink an eye when it comes to writing an adapter for my ObjectContext object. When working with an SMTP server, the adapter pattern once again comes to the rescue. This is especially true when I want to test that an email message was generated. It becomes really easy to write something like this:

mock.Verify(x => x.Send(It.IsAny<MailMessage>(), Times.Once());

But where should we draw the line? Just how much framework should have an adapter wrapper? What happens when I need to interact with the file system? What if I want to check that a directory was created or that a file was deleted? Do I really really on System.IO for that, or do I create a file system adapter, like IFileSystem with handy methods like CreateDirectory(string) and DeleteFile. This would be a crazy-easy interface and implementation to write, plus it would add the ability to test. What if I’m writing a Windows service and I want to verify that a Timer is created with a given interval?

But how much is too much? In a little project that I started, I recognized the following places where an adapter would be beneficial.

• File System: creating directories, deleting files, etc.
• Windows event log: verifying that events were written.
• Timer: verifying that a timer was started.
• Environment: the code should function as a command line executable and as a Windows service.
• Creating ZIP files. I’m talking to the Ionic.Zip library, which is code that I didn’t write.

By the time I was done with the code, I had more classes involved with wrapping an adapting, and a beautiful little architecture, than I had in solving the actual business problem at hand.

But at least everything was 100% testable.