My two cents on fakes, stubs, mocks, and shims

First off, let’s understand what unit tests are and why they are so important. A unit test may be defined as the smallest testable part in an application, and it’s a great way to write better, bug-free code. Unit tests help you detect and resolve bugs earlier in the software development lifecycle, in a process that tests units of code to make sure it conforms to the accepted results. This helps you write code that is modular and easier to maintain.

Incidentally, unit tests are methods that are written to validate a unit or block of code. You typically want the results from your unit tests to match the desired results. If they match, we say the test has passed; otherwise, they’ve failed. Unit testing if used properly in the development cycle of any application would ensure fewer errors in the application. In essence, unit testing is a discipline adopted by developers to minimize errors while the application is coming together. Unit testing is an integral part of the software development lifecycle and helps you verify any implicit and explicit assumptions made by your code.

Understanding fakes, mocks, stubs, and shims

Let’s now understand what fakes are and why stub and mock classes are important. Imagine that your unit test methods make calls to external components. In such cases, your unit tests become more complex as you aren’t sure if your code has failed due to the dependencies.

Here’s where fake implementations—also known as fakes, mocks, and stubs—come to the rescue. You can take advantage of Microsoft Fakes framework to test your code without having to bother about the external factors.

In essence, fakes help you test your code by replacing the external factors in your code. According to MSDN, Microsoft Fakes help you isolate the code you are testing by replacing other parts of the application with stubs or shims. These are small pieces of code that are under the control of your tests. By isolating your code for testing, if the test fails, you know where to find the cause. Stubs and shims also let you test your code even if other parts of your application are not working yet.

There are two types of fakes: stubs and shims. You can take advantage of stubs to test your code without having to deal with the dependencies directly. To replace the functionality with stubs, you should design your application in such a way that the components of your application makes use of interfaces. Note that you cannot use stubs with static methods, nonvirtual methods, sealed virtual methods, and sealed types—you are constrained to use stubs with interfaces only. In other words, you would have to rely on interface-based programming.

A shim is used to modify the compiled code at runtime. In doing so, your application would at runtime execute the shim code in lieu of the actual method call. Note that shims are slower in performance as they rewrite the code at runtime before the shim code can be executed. The choice between using stub and shim types depends on many factors, such as performance, static methods, sealed and internal types, private methods, and so on. A general rule is to take advantage of stubs for internal calls and shims for external assemblies.

When unit testing, you want to provide mock classes—that is, fake yet functional implementations of your code. You typically use mocks to test the interaction between your method that is being tested and its dependencies. Popular mocking frameworks include RhinoMock, Moq, and NMock. Essentially, you use stubs (a minimal representation of an interface that returns hard-coded data) to isolate parts of your application from each other so that unit testing becomes easy. I will discuss more on this topic in my future posts here with code examples for illustrating the concepts.