Skip to main content

Visual Studio 2012: Testing the untestable using Microsoft Fakes

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)

Fakes replace other components

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”:

image

This creates a System.fakes file within the project:

image

It also creates a Fakes folder containing a .fakes file for every fakes assembly we created:

image

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.

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more