Using Moq to Implement Tests (and Avoid Stubs)

In my previous post on understanding TDD I discussed how to analyze existing code for creating unit tests.  This was somewhat of “reverse TDD”, the idea being to look for what to needs to be tested- the relationship between what one class expects and what another class actually does.  Unfortunately I stopped short of actually implementing those tests- which is the subject of this post.

As a quick refresher, our demo app has some simple functionality which involves getting an order from a data tier then uses a shipping service to ship the order.  You can download the sample app here.

Prefer Mocking Over Stubs

Had I written this post about two months ago, I would have favored creating a suite of stub classes to mimic the expected behavior of our interfaces.  The approach would involve creating various stub classes for our dependent interfaces- the IShippingService and IOrderRepository- and plugging those stubs into the various unit tests.  In the simplest sense these would be hard coded classes to do what I wanted- from throwing exceptions to hard coding return values.  Probably even use some fancy random number generation for ids. However, I’m learning from a current project that the stub approach isn’t the best route to take.

The Problem, Distilled

Stubbing is definitely easy, but code quickly spirals out of control.  With stub classes, especially those backed by interfaces, more classes are created which then need to be managed and supported.  In an evolving software project this management creates added infrastructure which gets in the way when making changes to the original functionality.  An interface change, for example (either adding a new method or refactoring parameters) causes numerous changes to be made in stubbed out classes.  What’s worse, there can easily be a divergence in the behavior of the stubbed out class with the behavior it’s supposed to represent.  True, this can happen with mocking, but as we’ll see mocking is much more granular and can be tailored to specific circumstances with minimal code duplication.

There’s simply no need to create extensive, or multiple, stub objects with all those great mocking frameworks around.  Most mocking frameworks offer a ton of features creating granular control of expectations, return values, parameter verification, and method invocation checking.  I strongly recommend reading Martin Fowler’s Mocks Aren’t Stubs article for more information on the difference between mocks and stubs.

Using Moq to Mimic Behavior

We’ll use Moq 3 to demo what you can do with mocking.  Let’s start off with our first unit test, ShipOrder_Returns_New_Shipment_With_Order_Items.  We simply want to call our ShipOrder function and ensure we get a shipment back with shipment items.  To begin with, we’ll use Moq to mock our IOrderStorage and IShipmentService so we can construct our OrderShipmentManager.

[TestMethod()]
public void OrderShipmentManager_ShipOrder_Returns_New_Shipment_With_Shipment_Items()
{
var mockOrderStorage = new Mock<IOrderStorage>();
var mockShipmentService = new Mock<IShipmentService>();

var osm = new OrderShipmentManager(mockOrderStorage.Object, mockShipmentService.Object);

var shipment = osm.ShipOrder(5);

Assert.IsNotNull(shipment, "Returned Shipment was not null");
Assert.IsInstanceOfType(shipment, typeof(Shipment), "Returned object was not of type shipment.");
Assert.IsNotNull(shipment.ShipmentProducts, "ShipmentProducts were null");
Assert.IsTrue(shipment.ShipmentProducts.Count > 0, "ShipmentProducts were empty");
}

This test will fail because we haven’t specified any functionality for our interfaces!  But, we didn’t get a failing test with a null reference exception when calling GetOrder()- we got a failing test because our returned shipment object from GetOrder was null.  Stepping through code you’ll see that Moq returned void when calling the IOrderStorage.GetOrder method.  Moq creates a simple “dumb” proxy class for the interface automatically.  You can specify a strict behavior using MockBehavior.Strict in the constructor to throw an exception for anything that isn’t explicitly set up.  This can be helpful for ensuring control flow.

The solution to pass our test is to explicitly tell Moq what to do when this method is called, like so:

mockOrderStorage.Setup(os => os.GetOrder(It.IsAny<int>())).Returns((int id) => {
var order = new Order() { OrderId = id };
return order;
});

When working with Moq you may struggle with the extensive use of Lambda expressions the framework requires.  But after a couple of tests you’ll become a lambda ninja.  Moq relies on a pair of Setup/Return calls to dictate behavior.  Also notice how we didn’t have to implement every method in our interfaces- we only had to implement the ones we needed to make the test pass.  That saves a lot of code from being written!

The previous expression states “when you call GetOrder, with any int value, return a new order with the input id”.  Moq gives a lot of power in dictating the behavior of the return call based on the expected function.  By specifing (int id) in our return Lambda we can get a reference to our input parameter, which helps us construct a valid Order object based on any input. This is helpful when setting up exceptions.  By using a predicate expression with It.Is instead of It.IsAny, we can have our call throw an exception for an invalid input:

mockShipmentService.Setup(ss => ss.CreateShipment(It.Is<int>(id => id < 0))).Throws<ArgumentException>();

Setting up exceptions using Moq is instrumental in properly dealing with exception handling in your code.  Also, using It.Is to tailor return methods can help out when dealing with validation or verifying state.  It’s much faster and easier to use Moq to create behavior than hard coding stub classes.

There’s one final advantage to using Moq which you can’t easily do with stubs.  It’s verifying method invocation.  In our sample project, we have a call to _shipmentService.Ship(shipment).  What does Ship() do? It doesn’t return anything so checking a return parameter is difficult.  It doesn’t manipulate the shipment (or, let’s pretend it doesn’t).  We want to ensure this function is called.  The solution? Use Moq’s Verify() method, like so:

mockShipmentService.Verify(svc => svc.Ship(shipment));

This code will throw an exception if Ship wasn’t called with the shipment variable, ensuring that Ship was actually called if it should.  Using Verify() is helpful when testing out methods returning void- like sending an e-mail, doing a file operation, or ftp.

Conclusion

Spending some time getting up to speed with a mocking framework will be instramental in learning TDD.  It’ll also come in handy with just writing unit tests.  Mocking provides a simple, slimmed down solution that’s much easier to manage than stub classes.

I like Moq because it’s quick to express what you want done- but the heavy use of lambdas can be a struggle with getting started.  The moq quickstart is a great guide to the framework and covers all the bases.  The bottom line is don’t worry about which mocking framework you choose.  They all have their respective advantages.  Pick one, learn it, use it.  If you don’t like how it does something, switch to something else down the line which does what you want.

kick it on DotNetKicks.com

  • Pingback: DotNetShoutout

  • Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #295

  • http://wekempf.spaces.live.com wekempf

    Looks like you read the Martin Fowler article, and failed to understand it. Your test uses a stub, not a mock. According to Fowler, the big difference is in what your testing. With a Stub, your testing state. With a Mock, your testing behavior. You didn’t care if GetOrder was called, you only cared about the result (state) of the call to ShipOrder. This means you used a stub, regardless of whether or not the Moq uses Mock as the type name here.

    You seem to equate stubs with hand coded classes and mocks with runtime generated objects. This isn’t accurate, and either can be either hand coded or generated (runtime or compile time).

  • http://clariusconsulting.net/kzu Daniel Cazzulino

    I may add that the following lambda can be shortened significantly:

    mockOrderStorage.Setup(os => os.GetOrder(It.IsAny())).Returns((int id) => {
    var order = new Order() { OrderId = id };
    return order;
    });

    to

    mockOrderStorage.Setup(os => os.GetOrder(It.IsAny())).Returns((int id) => new Order { OrderId = id });

    (no need to do the var neither the return :))

  • Pingback: Mocking your dependencies away « DotManiac.Net – .Net & SQL-Server