Question

We’re currently following the DI model using Autofac as an IoC container.

We’ve recently started looking into mocking frameworks like MOQ and Rhino Mocks. However, we can’t seem to justify their usage over just creating Mock implementation classes for each of our interfaces.

Why do this:

var mock = new Mock<IFoo>();
mock.Setup(foo => foo.DoSomething("ping")).Returns(true);

Instead of this:

class FooMock : IFoo {
  bool DoSomething(string input) {
    return input == "ping";
  }
}
mock = new FooMock();

The latter is more verbose, but seems more flexible and appropriate for complex mocks.

Answer 1

What you have shown in your example is more of a fake/stub than a true mock and it is true that if you only want pre-canned behaviour from a dependent object then often a fake can be a better choice than using a mocking framework.

There is a canonical article by Martin Fowler discussing the fact the Mocks aren’t Stubs and I’ve lifted the following paragraph from it:

The key difference here is how we
verify that the order did the right
thing in its interaction with the
warehouse. With state verification we
do this by asserts against the
warehouse’s state. Mocks use behavior
verification, where we instead check
to see if the order made the correct
calls on the warehouse.

Essentially with mocks you are usually intending to check how your method under test acts upon the dependencies – your mock has expectations and you verify those expectations after the method has run.

You could of course still write your own case by case mocks but using a framework will save you a lot of time, give more readable tests and save on errors in the tests.

That is particulaly true as the expectations you have grow more complex, imagine having a method to test which calls a particular dependant class a variable number of times with varying values depending on input parameters – this would be complex to write a mock for yourself, but trivial using a good mocking framework.

To demonstrate with some code, imagine this PrintOrders method (excuse the silly example):

public void PrintForeignOrders(List<Orders> orders)
{
    foreach(var order in orders)
    {
        if (order.IsForeign)
        {
            printer.PrintOrder(order.Number, order.Name);
        }
    }
}

You would probably want to test at least:

• When the list is empty nothing is printed
• When there is a foreign order it is printed
• When there are two orders both are printed (with the right number and name)

With a good mocking framework setting up those tests against the injected printer object is just a matter of a few keystrokes.