I’ve been thinking for a while: “How come Microsoft doesn’t have a Mocking Library like Moq, Rhino Mock, NMock, Typemock, etc?”. Off course you could argue that we don’t need one of our own, you could use one of the existing once or you could just implement some stubs yourself. I’ve lately been drawn towards Moq for its great support for refactoring, but Rhino Mock is the framework I’ve used the most.
Last night, I discovered something fun though. It turns out that Microsoft Research have been busy with something called Microsoft Moles and a first release is now out for you to try out. Let me introduce Microsoft Moles to you by this example.
Let’s say you have this simplified WCF Order Service, implemented like this:
So lets create some Unit Tests for this WCF Service, but first, let us recapture what a Unit Test really is. A Unit Test is a test that tests the smallest testable part of your code. In a unit test we don’t want to be dependent of other parts of our system and specially not dependent of other products like the file system, a SQL Server or any other third party application. Don’t get me wrong here, you could and perhaps should write automatic tests that test the integration between several components and applications, but those tests are not Unit Tests, those are Integration Tests. In a unit test we want to isolate our test to test only one (or the smallest) part of our code.
If you look at the implementation of OrderService above, you can see that we have a strict dependency for a class called OrderRepository at row 40, that seems to save our order to a database and returns a new OrderId. This is a problem for us because we can not test our OrderService without testing our OrderRepository as well.
Another problem can be found at row 37 where we set the OrderDate to the current date and time. How can we predict that value? We don’t know at what time our test is going to be run.
The traditional way to fix this problem is to refactor the original code to implement some kind of pattern that helps us substitute our hard coded dependencies. One popular pattern is the Dependency Injection Pattern which essentially says that every class should take its dependent objects as in-parameters to its constructor (or through properties). I won’t go in to that pattern right now, but this is a good pattern and as I’ll try to cover in a follow up post, I’ll show you how Microsoft Mole might help you even though you have decided to use this pattern.
But if we don’t want to or are unable to refactor our code, how do we do then? This is when Microsoft Moles comes as a savior. With Microsoft Mole, you can substitute almost any .NET method with a version of your own. Yeah, that’s right. If you don’t like the current implementation of DateTime.Now, you could substitute it to always return a date that you control or if you don’t have full control of what the AddOrder method on the OrderRepository does, then substitute it for another implementation. Let me show you.
At line 9 above, you can see how I substitute the current implementation of DateTime.Now with an own implementation that always returns 2010-03-07 14:20:00. You can see that I use a “Magic Class” called MDateTime to do that. And on line 11 you can see how I replace the current implementation of SaveOrder of the OrderRepository class by interacting with another “Magic Class” called MOrderRepository. As it turns out, this is no magic at all.
Microsoft Moles generates classes for me according to my specifications in .moles files and in this example I’ve configured Moles to generate Mole Types for mscorlib.dll and my service library. You can configure exactly what classes gets generated to save some execution and generation times, but in this example I’ve just let Moles to generate Mole Types for the complete assemblies.
Content of: mscorlib.moles
Content of: AI.ServiceLigrary.moles
Moles also made me aware that I had to add the following attribute at assembly level, which I did in my AssemblyInfo.cs file:
So, that’s it, when I run my Unit Test, and yes this is really a Unit Test and not an Integration Test, it passes and informs me that my AddOrder method inside my OrderService works as it should. Just to prove that I’m not doing Integration Testing here I’ll even show you my implementation of my OrderRepository:
Amazing, isn’t it? We have just made a Unit Test out of code that normally isn’t Unit Testable at all. With that said, I still like to point out the following:
- Microsoft Mole is a great! It can help you Unit Test what wasn’t unit testable before (actually some Mocking Frameworks like Typemock have made this possible before).
- I still want my systems to be loosely coupled and would still recommend you to implement some patterns to make your system just that. Just because Moles might save you some troubles of implementing one of those patterns, doesn’t make it necessary a good thing.
- Make sure you understand how to implement the Dependency Injection Pattern and know how to use Inversion of Control Containers like Unity, NSpring, etc. Microsoft Moles can also help you implement the stubs you would need to Unit Test you components that implements the Dependency Injection Pattern.
- Microsoft PEX is a tool that will help you implement Unit Tests with high code coverage and is a very interesting technology. Make sure you’ll have a look at that as well. I might even cover that topic later as well.
Please look at this post on the Visual Studio Team Test blog to find out more information and how you can download Pex and Moles.