Testing the untestable
To test your code in isolation, Mocking frameworks like RhinoMocks or Moq are an important tool in your toolbox. By using an isolation(mocking) tool, you can replace an existing object by a ‘fake’ implementation. Unfortunately these tools cannot help you solve everything. If your system is not designed with testing in mind, it can be very hard or even impossible to replace an existing implementation with a mock object. Let’s for example take DateTime.Now. This is a static property on a static class, how are you going to replace this?
Let’s have a look how Microsoft Fakes, the isolation framework that Microsoft introduced in Visual Studio 2012.
Microsoft Fakes
Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with stubs or shims.
-
A stub replaces another class with a small substitute that implements the same interface. To use stubs, you have to design your application so that each component depends only on interfaces, and not on other components.So this is similar to the functionality that most other mocking frameworks offer.
-
A shim modifies the compiled code of your application at run time so that instead of making a specified method call, it runs the shim code that your test provides. Shims can be used to replace calls to assemblies that you cannot modify, such as .NET assemblies.(It is using the Moles Isolation Framework behind the scenes)
So what does this mean? By using the ‘shims’ we can isolate any kind of functionality inside our .NET application, including non-virtual and static methods in sealed types. No longer we are limited to to interfaces or virtual methods to replace dependencies.
Remark: Using Shims has a performance impact on your tests because it will rewrite your code at run time.
How to use Microsoft Fakes?
Let’s walk through an example. In this sample I want to test the SmtpClient, preferably without sending real emails. Below you’ll find the MailService class I want to test. This class has a direct dependency on the SmtpClient making it hard to test:
The SmtpClient class lives in the System assembly. To create a shim for this class, go to the Test Project, right-click on the System assembly in the references for the project, and choose “Add Fakes Assembly”:
This creates a System.fakes file within the project:
It also creates a Fakes folder containing a .fakes file for every fakes assembly we created:
Inside the System.fakes file, we can specify for which types a shim should be created(for some types, this is done by default):
Let’s now write our test. Start by creating the test method and specifying the ‘arrange’ part:
Now we continue by adding the ‘act’ and ‘assert’ part of our tests. Because we want to use shims, we’ll have to wrap our calls into a special ShimsContext. The Microsoft Fakes framework created a ShimSmtpClient in the System.Net.Mail.Fakes namespace. On this ShimSmtpClient, we can overwrite the SendMailMessage method of all SmtpClient implementations through the Action<SmtpClient,MailMessage> property available on the AllInstances property:
This naming convention is used for all shims you create in your test application.