The advent of unit testing frameworks within the past few years has given the development community valuable tools that can help to create high-quality systems.  Systems built using rigorous unit testing during the development cycle tend to generate fewer defects found during integration testing.  A unit testing framework allows a developer to create tests that can be executed against their code to ensure that it functions correctly. The unit testing framework that is included with VisualStudio is one such example.

With VisualStudio it’s possible to create unit tests that can exercise the methods of a class, and verify that the class performed correctly. In a perfect world, as a system is in the design and development phase the unit tests would be developed at the same time. However, we all know that we don’t live in a perfect world.  If unit tests are developed at the same time that the application code is being developed, then the system will be easier to test because it was designed with testability in mind.  There is a previous blog post about Inversion of Control and Dependency Injection which describes a design principle that helps to create loosely coupled systems.  A loosely coupled system is easier to test because the dependencies of the class can be mocked by the testing framework without changing the execution behavior of the code under test. A secondary concern when building testable systems is that if a class modifies other objects, there needs to be a way for the unit test to assert that the state of the modified objects is correct.

If you maintain an application that was not designed with testability in mind, you may be struggling to figure out how to develop a unit test to exercise your code.  There is an Isolation Framework called Moles form the Microsoft Research group that may be able to help.  The Moles framework can be used to make testing easier by intercepting calls to methods and replacing them with delegates that you provide. This article is about how to use the Moles Isolation framework. Consider the following method, and think about the difficulties in testing this.

Both of the repository classes will make calls to the database to fetch entities (lines 17 and 20). In order to unit test this method we would rather not make the database calls because it assumes that a suitable database is populated with customers and orders. Rather, we’d like to supply a mock of the method calls on line 17 and 20 so that we can inject customer and order data into the unit test. The Moles Isolation framework can do this.

A second problem with this method is that there is no obvious way to validate that the ShipDate of the order has been set properly (line 24) after the Process Order method completes.

Moles Isolation Framework
The Moles framework can be installed as a Visual Studio Extension. Open the Extension Manager and search on “Moles”. There is a framework to download and install on 64-bit computers, and one for all others.

How to use Moles
Once the Moles framework is installed, it is ready to use. The Moles framework can instrument any assembly that is referenced by the testing project. In order to do this, open the testing project from inside of the Visual Studio Solution Explorer, and view the project references.

In the Testing Project we need to create a Mole assembly of the “Framework” project in order to Mock the repository methods.   Select the Framework project reference, right-click on it, and in the context menu select “Add Moles Assembly”. This will add an additional project reference to an assembly called “Framework.Moles”.  In addition, a reference to the assembly Microsoft.Moles.Framework, will be added if necessary. Now, let’s look at how we can test the OrderProcessingEngine.  Here is start to a standard unit testing method that will exercise the ProcessOrders method:

Nothing terribly fancy, but we know this will not work properly because the engine will cause database queries that we know we need to mock.  In order to use Moles to mock the CustomerRespository’s method GetCustomer, we need to add the following to the testing method:

Notice the addition of lines 94-100 to our unit test. The Moles framework has created an assembly with classes that can be used to mock the application code. All moles classes will be in a new namespace. The original application namespace is appended with a “Moles” qualifier.  Notice the namespace on line 94 of “Framework.Repository.Moles”. The namespace of “Framework.Repository” comes from the original application code. The moles class allows a delegate to be supplied which will stub the method call at runtime of the unit test. When the unit test executes, the delegate found in lines 97-99 will run in place of the original application’s CustomerRepsoitory.GetCustomer() implementation.

Notice on line 90 the attribute [HostType(“Moles”)]. This is used by VisualStudio to execute the testing process using the Moles framework’s runtime hosting environment. Now, in order to create the stub of the OrderRepository method the unit test method look like this:

The code found in lines 104-113 will stub the call to OrderRepository.GetPastDueOrders. Because we can supply our own delegate in order to stub the repository method, this also means that we can save the intermediate entities of Customer and SalesOrderHeader returned by the repository methods. This will allow us to interrogate the entities and assert that the unit test executed successfully. The complete testing method, will assertions is as follows:

Now, when the unit test runs, there will be no database calls because the stub of the repository methods returned hard-coded entities. The assertions will validate that the test executed correctly and that shipDate of the order is set correctly.  Refer to the ProcessOrder method found near the top of this article and notice that when orders are processed, the ship date is set to today’s date. The unit test will pass, and life is good. Now let’s look at a slightly different application code method that should be unit tested:

The NotifyBillingSystem method is tightly coupled to use Message Queuing to send messages to a queue that the Billing system monitors. The Moles framework also works with .NET System assemblies, in exactly the same manner as application assemblies. We can create a mole of the System.Messaging assembly and the following unit test will stub the call to the MessageQueue.Exists method, the MessageQueue.Send method as well as the constructor of the MessageQueue class.

What it means
The Moles Isolation Framework from the Microsoft Research group can be used to create unit tests for code that may otherwise be difficult to test.  Code can be difficult to test because it is either tightly coupled to an implementation, or it does not provide a way to verify side effects on state data. The Moles Isolation framework can help.

Where to get more info
Moles Isolation Framework