Having a chat with a colleague the other, brought up the issue of strict mocks. I commented that strict mocks should be used sparingly and only in certain circumstance, and this led to a series of discussions on why that is.

Strict and loose Mocks

Usually mocking frameworks provide two types of mocks: strict and loose. If you're using RhinoMocks, these are called StrictMock and DynamicMock. If you're using Moq, you set the behaviour (Loose = Dynamic = Default or Strict) in the mock creation.

RhinoMocks

RhinoMock has a static mock repository that you can use to create mocks, called MockRepository. This saves you on having to explicitly create a mock repository. Thus, instead of doing:

Using the static repository, you cannot pick between dynamic and strict mocks. All mocks are dynamic. This somehow promotes the usage of dynamic mocks over strict ones.

Moq

With Moq, as with RhinoMocks, the default behaviour is of loose mocks. Thus, writing:

1: var dependency = new Mock<IDependency>();

is equivalent to:

1: var dependency = new Mock<IDependency>(MockBehavior.Loose);

which in turn is the same as:

1: var dependency = new Mock<IDependency>(MockBehavior.Default);

If you want to use strict mocks:

1: var dependency = new Mock<IDependency>(MockBehavior.Strict);

(Note that with Moq, to access the actual Mocked object, you need to access the .Object property. RhinoMocks doesn't require this because it uses extension methods).

Using Strict Mocks

So, now that we know how to create the two different types of mocks depending on the framework, let's take a look at a SUT and see where the problem with strict mocks lie. To make the post shorter, I'll use RhinoMocks, but you can accomplish the same with Moq.

Suppose we have the following class:

1:publicclass ServiceClass

2: {

3:privatereadonly IDependency _dependency;

4:

5:public ServiceClass(IDependency dependency)

6: {

7: _dependency = dependency;

8: }

9:

10:publicvoid FirstMethod()

11: {

12: _dependency.FirstMethod();

13: Console.WriteLine("Called ServiceClass.FirstMethod");

14: }

15:

16:publicvoid SecondMethod()

17: {

18: _dependency.SecondMethod();

19: Console.WriteLine("Called ServiceClass.SecondMethod");

20: }

21: }

and we want to test that when calling ServiceClass.FirstMethod, the corresponding call Dependency.FirstMethod is called, we could be tempted to do something like the following:

With strict mocks EVERY single call to the mocked object has to have expectations set on it. If we make an additional call and we don't set the expectation, our test will fail. Our test was to verify the FirstMethod was being called, and it still is. Our test failed because we wrote it using strict mocks, it failed for the wrong reason, and made our code very brittle.

However, if we were to have written the test using Dynamic mocks, this wouldn't happen:

Mocks are a great thing to test behaviour between different components. However, make sure you use them correctly if you don't want to end up with brittle code that any minor change breaks a whole bunch of tests. Strict and ordered mocking should only be used in exceptional cases.