Published: 20 Apr 2009
By: Gabriel Schenker
Download Sample Code

This article gives a quick introduction in the usage of two of the most known mocking frameworks: Rhino Mocks and Moq.

Contents [hide]


When using TDD [1] to develop an application it is essential that the system under test (SUT) can be tested in isolation. That is, only the class that I am currently developing is “real” and all other parts are simulated or faked. If my SUT needs to collaborate with other components those other components are mocked during the test. We can either manually implement such mock objects or use a mocking framework for this task. There exist several well known mocking frameworks for the .NET platform. In this article I’ll give a short introduction in the two most used OSS mocking frameworks. The first is Rhino Mocks [2] which was developed by Oren Eini, aka Ayende [3] and the other one is Moq [4] developed by Daniel Cazzulino [5].

Preparing the System

To start using one of the mocking frameworks you have to first download it. You can do this here [2] if you want to use Rhino Mocks or here [4] if instead you want to work with Moq. Both frameworks are part of the code accompanying this article. You find the libraries needed in the lib sub-directory of the download.

Create a new folder on your system. Call it MockingSample. Create a sub- folder called lib and copy the files nunit.framework.dll, rhino.mocks.dll and moq.dll into this directory. As mentioned above you find these three libraries in the lib folder of the code to download.

Mocking Basics

The easiest way to generate a mock object is to provide an interface to the mocking framework. The framework then creates an implementation of this interface which is automatically instrumented such as that behavior of the system under test can be verified through the mock object.

A mocking framework like Rhino Mocks can also mock an existing implementation. But there is one caveat; the methods called must be virtual. The reason is that the mocking framework automatically “wraps” the component to be mocked into a proxy object. To accomplish this he proxy object inherits from the component and overrides the members. But only virtual members can be overridden.

If you cannot mock an object since it implements no interface and its methods are not virtual you can still build a thin wrapper around the object to mock and then mock the wrapper during the test. This is also called the adapter pattern [6].

Why should I use mock objects?

Imagine you want to develop an order service which needs some data from the database. The SUT in this case is the order service. We want to test this order service in isolation. Why? It is not always possible or it is too much work involved to provide e.g. a real database with realistic data to the developer during testing. Doesn’t it make sense in such a situation to replace the real database access with a faked one? Another scenario is the following: you have to implement an email publisher which sends emails to subscribed people when some event in the system happens. During the test you do not want to send real emails to people. You don’t want to be identified as a spammer, don’t you? In such a situation we mock the email sender.

But let me say the following: not every object must be mocked. It makes absolutely no sense to mock an object that is a pure data container and has no behavior or any external dependencies. Typical examples of this kind of objects are the so called data transfer objects (DTO). Such objects can be used as they are and must not be faked.

A simple use case

We have to develop an order service. The order service creates new orders with the aid of an order factory and retrieves pre-existing orders from the database through an order repository. Whenever a customer that has unpaid orders places a new order an email is sent to the manager for approval of the new order.

In this simple sample we can already identify three components which collaborate with the order service. These are the order factory, the order repository and the email sender. Those three components we will want to mock when implementing and unit -testing the order service.

You will realize however that this list is not complete. There will certainly be other components to mock whilst developing the order service.

Domain Model

In the picture below you can see the class diagram of our simplified domain model. There is an order service class which has three external dependencies. All dependencies are tied to interfaces and NOT to implementations. This makes unit testing very easy since all three dependencies can be easily mocked during the test.

Figure 1: The domain model

The domain model


The first operation we want to implement is the PlaceNewOrder method of the order service. We want to do this test driven. Thus I prepare my solution accordingly and create the following solution structure.

Figure 2: Structure of the solution

Structure of the solution

The project named Core contains the logic to implement and the project called UnitTests contains all unit tests or, as I prefer to call them, the project contains the specifications. To streamline my specifications I use to work with a SpecificationBase class. This class is very simple but it allows me to implement my specifications in a BDD [7] like manner, that is I use the schema Given->When->Then.

The Given method contains all code needed to setup or prepare the test or as one also says: to prepare/define the context. The When method will contain the operation (-call) we want to test. The Then’s are the individual test methods which will be decorated with the Then attribute.

To support the usage of the Given->When->Then syntax I also need to implement a special attribute which derives from the TestAttribute of NUnit. I call this the ThenAttribute.

Now finally let’s see some real code. I create a specification for the task I want to accomplish. The name of the specification class should reflect my intent. In this case my intent is to place a new order. Thus my definition is as follows

Note how the name of the class is rather long (this is desired) and starts with the prefix when.

Introducing Rhino Mocks

Now to be able to place a new order the order service needs an order factory. This order factory will be mocked. The mocked order factory will then be injected into the order service via the constructor. All this is setup code and will thus be placed into the Given method of my specification. A new order is placed by a specific customer so I’ll also need an id for this customer.

Note the first line in the Given method. That’s how Rhino Mocks can be used to create a mock based on a given interface. Just call the static and generic method GenerateMock of the MockRepository class. Here Rhino Mocks will automatically generate an implementation for the interface IOrderFactory and return this implementation and assigns it to the field orderFactory. In the second line the mocked factory is injected into the service. It is very important to note that the order service will NOT realize that the injected factory is not the “real” factory but just a mocked one. The order service only realizes that it receives an object which implements the expected interface IOrderFactor.

Now let’s specify the actual operation we want to implement. This is done in the When method of the specification. In our case

Obviously I call a method PlaceNewOrder (which has to be implemented afterwards) and pass it the previously defined customer id.

Now I want to use my mock object (together with the mock framework) to verify expected behavior of the order service. In this case I want to verify that the method PlaceNewOrder calls the method Create of the order factory and passes the right parameter (the id of the customer). This verification I will implement in a method that I decorate with the Then attribute. The code needed to verify my expectation is

This is a very short assertion but it looks quite strange if you are not used to lambda expressions [8]. But it’s quite easy to explain what happens. The Rhino Mocks framework defines an extension method [9] AssertWasCalled which can be applied to any object. Here it is used on the mocked order factory. The lambda expression factory => factory.Create(customerId) which is passed as a parameter tells the mocking framework which operation we want to assert. In this case it’s a call of the method Create on the mock object. Not only do I expect a call to the method but also the parameter(s) of the call have to be as expected.

If I want to have more control over the expectations regarding parameters of a call Rhino Mocks offers different possibilities. The following line of code just expects a call to the Create method but the parameter is ignored

The above code uses the second overload of the AssertWasCalled method which expects a lambda expresssion which defines constraints or expectations on the parameters. In this case we have declared by the expression c => c.IgnoreArguments() that we want to ignore any argument of the call. Note that we still have to pass some value as parameter and in this case I have chosen to pass the Guid.Empty value.

Now I also want to show how we can instrument the mock object such as that it e.g. returns a specific value when a certain method is called. In our case I’ll illustrate that with the order factory mock object. The mock object shall return a prepared order object when we call its method Create. This instrumentation is part of the setup code and thus belongs into the Given method of our specification. With the following code

I first line I define a new (dummy) order object and then specify in the second line that the mock object should return this dummy object when called. Note the Stub method which is also an extension method defined by the mocking framework. Note also the Return method which allows me to instrument the mock such that it returns precanned data.

Discussing Moq

The Moq framework is very similar to Rhino Mocks. To create a new mock object we do not use a static method but rather instantiate a generic mock object

The type of this object is Mock<IOrderFactory> which is different compared to Rhino Mocks. We have access to the mocked object via the property Object of the mock. Thus instantiating the factory service and injecting the mocked factory the syntax is as follows

To verify behavior Moq uses the method Verify of the mock object. This method also expects a lambda expression similar to the one used with Rhino Mocks. If we want to verify the call and the parameters the code is like this

If we only want to verify the call regardless of the parameter passed we can do this like so

The full code of the unit test using Moq is shown below

Evidently it is very similar to the one needed when using Rhino Mocks.


In this first part of a series of articles about mocking frameworks I have introduced the concept of mocking and the reasons to do so. I have defined a simple yet realistic use case and have demonstrated within this use case how Rhino Mocks or Moq can be used to mock external dependencies of the component or class I want to test.

In the next part of this series I’ll show some advanced usage scenarios and how the two mocking frameworks can be used in these situations. Stay tuned.



In this article I have given a quick introduction in two of the most known mocking frameworks for the .NET platform. I have shown how either of these two frameworks can be used to create and configure mock objects. I have also shown how behavior of the system under test (SUT) accessing these mock objects can be verified. Both frameworks allow the developer to develop a new class in complete isolation when simulating all other components by mock objects.

<<  Previous Article Continue reading and see our next or previous articles Next Article >>

About Gabriel Schenker

Gabriel Schenker is a independent consultant, trainer, mentor and developer. He lives in Switzerland near to Zurich. His special focus is on practicing lean or friction-less software development. This includes practicing TDD, BDD and DDD. He is constantly advocating, promoting and supporting a cont...

This author has published 4 articles on DotNetSlackers. View other articles or the complete profile here.

Other articles in this category

Introduction to StructureMap
Have you heard of StructureMap, generally know what it’s for, and want to know how to get started qu...
DI Patterns: Constructor Injection
In this article, an excerpt from the book "Dependency Injection in .NET", we will take a detailed lo...
The Command Pattern
In this article I will provide a quick refresher on what the command pattern is used for, how it wor...
TypeMock’s Arrange-Act-Assert
Brian Mains discusses how to implement the Arrange-Act-Assert pattern in TypeMock.
Key Process Patterns
This article, based on chapter 2 of Specification by Example, presents effective patterns for softwa...

You might also be interested in the following related blog posts

Introducing SharePoint 2010 Training at U2U read more
The Underground at PDC read more
10 resources to learn Moq read more
My History of Visual Studio (Part 6) read more
Why not Classic (Legacy) ASP? read more
BeginDialOut with Office Communicator Clients read more
SOA Patterns presentation on E-VAN (recording) read more
DotNetNuke Fusion Results for Q3 read more
Successive Method Calls With MoQ read more
GiveCamps Get a new Sponsor read more


Subject Author Date
placeholder Great Job!!! df fd 4/21/2009 2:13 AM
Download Sample Code Not working. df fd 4/21/2009 11:53 AM
placeholder RE: Download Sample Code Not working. Sonu Kapoor 4/22/2009 10:14 AM
RE: RE: Download Sample Code Not working. df fd 4/22/2009 12:07 PM
placeholder RE: Download Sample Code Not working. Sonu Kapoor 4/21/2009 11:56 AM
Very Informative Tom Granados 2/4/2013 9:33 AM

Please login to rate or to leave a comment.