2019 / 10 / 23
In software testing, it is not always easy to decide which mocking framework to use. STOP!!! But do you know what Mocking Framework means?
Mocking if we talk in literal terms means an imitation of something. If we talk in terms of software testing, then mocking means to replicate a functionality or an entity that is not present at the time of testing a unit. By now you must have guessed that Mocking is used in Unit testing.
In Unit testing, all of you must be aware that testing is done on individual units or modules. A unit or module that you want to test may have dependencies on other modules, where the other module may not be fully developed. In such a case, you may want to replace the module with the mock module, so that the dependent module can function properly and can be tested without any hindrance.
There are a lot of frameworks that are available out there in the market like PowerMock, Moq, NSubstitute, EasyMock and many more. The problem comes when we have to decide which mock framework to use. If we talk about Microsoft Visual Studio the most obvious choice is VS built-in Microsoft Fakes Framework but some may want to consider third party Mock Frameworks- Easy Mock, Moq, etc.
Till now we have discussed why we need Mock Frameworks. But you must be wondering how they work? How they replicate the functionality? Let’s dive into the details of the functioning of Mock Frameworks.
Like we have discussed earlier, Mock Frameworks are designed to solve the problem often faced in Traditional Testing where we want to test modules for their interactions with external sources or some dependencies that are still in the development phase. In such a case, Mocks are used to simulate the functionality of external source or dependency.
Mock Frameworks have 3 ways to simulate the dependency or external source or any entity: Mocks, Stubs and Shims. All 3 have different purposes, but their definition is quite similar to each other due to which they may seem similar but they have a completely different agenda. Let’s begin discussing each of them in a bit detail.
Mock: The key point to understand and remember here is that Mocks are interface based. This means they interact with the code being tested by means of interfaces. This also means you need to generate interface-compliant code for Mocks. Since Mock is intended to be an exact replica of the actual object, so there should be no difference between them. Otherwise, the whole purpose of creating Mock will fail. There are certain features that are important for a replica object to be called Mock:
We have discussed a lot about Mock Frameworks. We will not be discussing examples of third party Mock Frameworks instead we will be focussing on Microsoft Fakes in this blog post.
The agenda behind discussing Microsoft Fakes in this blog post is because for Microsoft Visual Studio, Microsoft Fakes is built-in. So, this means you don’t need to do the setup process for using Microsoft Fakes.
All you need to do is to use the “Add Fakes Assembly” option and add fakes or we can say generate stubs for every interface in the assembly. The process of generating and using Shims is integrated in a similar manner.
I have a big fact to tell you now, you must be thinking about how to get started with Mocks in Microsoft Fakes. Let me tell you THERE ARE NO FULL MOCKS IN MICROSOFT FAKES. Yes!!! You heard me right. This is the most controversial feature of Microsoft Fakes.
But this does not mean you cannot create stubs with mocks like functionality. Remember the complex logic part that is specific for Mock not found in Stubs. You can do this but you have to take care of them, you have to create them and do the housekeeping. Since they are not built-in so don’t expect Microsoft Fakes to do this for you.
It will only handle Stubs and Shims.
Microsoft Fakes built-in support for Shims is not that happily acceptable for some community of developers. But Why?? The reason is very simple, do you remember that I have mentioned earlier that shims are not interface based. This means generating code that is not interface-compliant may prove to be an invitation for broken dependencies in the future. Like there is a pro for every con, there are some defenders also, you say not-interface interactions are sometimes unavoidable. So, it is completely up to you to decide when and how to use Shims or to skip them completely.
Microsoft recommends that shims should be used in scenarios where external resources are one with static, non-virtual or private methods. They also highlighted one more important point about shims. Shims functions by creation detours, which naturally happens at run-time, which will eventually slow down execution. This does not happen with Stubs.
Now, you know all the pros and cons of Mocks, Stubs, and Shims. It is completely your decision on which one to use.
One last thought I wanted to discuss is, what to use Microsoft Fakes or third party Mock Frameworks while using Visual Studio. See, the logic is quite simple. Since Microsoft Fakes don’t have provision for full mocks, this means we cannot test complex dependency interactions. In such a case it is advisable to use third-party Mock Frameworks.
In this blog post, we made an effort to help you with why to go and not go with Microsoft Fakes. Why we have Mock Frameworks in the picture.
Be wise, choose wisely, you will be able to test with the least resources and with a high success rate. In the end, it’s your choice how to fake it.