This post covers about the code samples of using Moles for a few of the commonly recurring scenarios. I have created a small project with/without following proper design principles for brevity purpose, and also to demonstrate how moles helps us in testing any module, which was not built with testability in mind. Adding a caveat, the code and the explanation are kept very simple and basic that the advanced users of moles might not find this post fully useful.
One important point to be kept in mind while Moling (the act of mocking any type with moles) is “The mocked implementation should always be done before the actual execution happens.” If not the mocked behavior will not be in effect and could lead to unexpected results in the unit tests.
Mocking Constructors :
Consider a typical 3 tier application, where the business layer’s classes instantiate their corresponding data access layer’s objects, and the data access calls happens in various methods with this object. While unit testing the business layer methods in isolation, we don’t really need to bother what the data access layer does. To isolate this, we would have to mock the implementation of data access object instantiation and its methods. Consider a class as shown in the screenshot. This class instantiates the data access object directly inside its constructor. This is clearly a design principle violation, as none of the classes should directly refer to other implementations. Yet, if in cases like this, how the methods of MyMolesDemo can be tested without instantiating MolesDemoDataAccess object.
Business Class under Test:
Data access class, the business is dependent on
Data access base class, which sets the connection string property for the data access operations
Unit test method:
MMolesDemoDataAccess is the moled type for MolesDemoDataAccess and that exposes a delegate for the constructor “MMolesDemoDataAccess.ConstructorString” which can be used to mock the behaviour of actual MolesDemoDataAccess. This will help in successful creation of MolesDemo object without the data access object instantiated. Snapshot of the business object given below.
Mocking methods for “AllInstances” :
In the previous snapshots, we saw how constructor of any type can be moled. The unit test also has the piece of code to mole the methods of data access object.
MMolesDemoDataAccess.AllInstances.LoadInt32 = (dataAccessInstance, limit) =>
{ return new List<string> { “string1”, “string2” }; };
Since we have not created any instance of Data access object in this case, we can make use of AllInstances property of the moled type to mock the behaviour of the Load method. While mocking using AllInstances, we would have to provide an extra parameter to the method being mocked. The first parameter it takes would be the type of the instance being mocked, followed by the parameters of the method
Mocking specific instances of a type:
Consider the type MolesDemo has a bunch of methods in it, and a single wrapper kind of method which just invokes subsequently various other internal methods of the type, then we can mock a specific instance of MolesDemo rather than using “AllInstances”.
Method to be tested:
As you can see, this method does have a lot of If…Else, that means more scenarios to be unit tested to get a complete code coverage. In these cases, we can mock the output of the intermediate method calls per the flow we want to test. Snapshot of one such test method which tests the happy path scenario is given below:
In this test, we are passing the instance of Stubbed version of MolesDemo instance [the actual object to be tested] to the moled version of it. This way, we would have the luxury to mock a portion of the object’s methods while executing the rest of it in its actual implementation.
SMyMolesDemo target = new SMyMolesDemo();
MMyMolesDemo moledInstance = new MMyMolesDemo(target); // moling the behavior for a specific instance of MyMolesDemo class
Mocking Static Types:
Mocking static types is no different from reference types. Only difference being, AllInstances property wouldn’t be available for static types and it is not possible to instantiate the moled type for the obvious reason that it is static. Rest all remains the same, attach a delegate to the static method you want to mock and execute the test method.
More on the code samples for mocking generic methods, mocking the framework dlls, using stubs for mocking classes with virtual methods, and the link for entire code dump used in this post are underway in the next post.
Swaminathan Vetri 
pinran yaaaaa