Mocking frameworks: stubs vs mocks

I just answered another question on stackoverflow about Rhino Mocks. The issue in the question comes down to a confusion between mocks and stubs as it often does. Stubs and mocks are both test doubles (i.e. a way to quickly replace a real class implementation by one that you have full control over) but they are set up in different ways.

The distinction between mocks and stubs also exists in other mocking frameworks such as jMock for java. It is important to understand the difference if you are going to do TDD with a mocking framework which supports both approaches.

Mocks

A mock is a test double where you set up behavior by providing a sequence of expected method calls and the corresponding return values. You can think of a mock as an actor in a play who has to follow a script. The script specifies both expectations (i.e. what the other actors will say and when they'll say it) and behavior (i.e. how to respond).

In practice, such a test script is recorded by making calls on the mock. After the behavior has been set up, you must explicitly switch a mock from record mode to replay mode. At the end of the test the expectations are verified. This is how it looks in Rhino Mocks:

[Test]
public void Eat_uses_banana_provider()
{
   var mocks = new MockRepository();
   var bananaProviderMock = mocks.DynamicMock<IBananaprovider>();
   bananaProviderMock.GetBanana(); // record method call expectation
   LastCall.Return(new Banana()); // tell mock what to do
   bananaProviderMock.Replay(); // stop recording, go to replay mode
   
   // actual test
   var monkey = new Monkey(bananaProviderMock);
   monkey.Eat();

   // verify the expectations that were set up earlier
   bananaProviderMock.VerifyAll();
}

Actually, I lied: this is just one way how it can look. Unfortunately a lot of cruft has accumulated in Rhino Mocks (presumably for backwards compatibility) and it has become hard to tell which is the recommended syntax.

Stubs

A stub is a test double that, unlike a mock, has no concept of a "test script". There are no separate record and replay phases: you just set up canned answers for method calls. Setting up this behavior will not create any expectations. Instead, the stub will record how it is used so that you can make assertions separately at the end of the test. In Rhino Mocks it looks like this:

[Test]
public void Eat_uses_banana_provider()
{
   var bananaProviderStub = MockRepository.GenerateStub<IBananaprovider>();
   bananaProviderStub.Stub(x => x.GetBanana()).Return(new Banana());
   
   // actual test
   var monkey = new Monkey(bananaProviderStub);
   monkey.Eat();

   // make assertion about how the stub was used
   bananaProviderStub.AssertWasCalled(x => x.GetBanana());
}

Use stubs instead of mocks if possible

There are a few reasons to use stubs instead of mocks if possible:

• Mocks are more powerful than stubs because they can do things like giving different answers for the first and second call. However, this will make your test much harder to understand.
• Mocks make it hard to create tests that test only one thing. If the monkey class starts creating its own bananas after a change, then ideally only the Eat_uses_banana_provider test fails. If every monkey test starts failing you will waste time diagnosing the exact problem.
• Mocks lead to brittle tests because they expect a certain sequence of method calls. Unless you are explicitly testing that something happens in the expected order, this is rarely what you want.

If you must use mocks, use dynamic mocks rather than strict mocks (Rhino Mocks offers both). Dynamic mocks will not throw exceptions when they receive an unexpected method call. They will return a default return value if necessary (e.g. 0 or null) and will keep on trucking.

Because of the disadvantages, Moq (a popular and simpler alternative to Rhino Mocks) doesn't even offer the record/replay approach.