Recently I’ve been planning to contribute to the rhino mocks wiki. One of the topics I thought I would write about is when I would use the different types of mock (CreateMock, DynamicMock, Stub etc). To this end I was trying to think why you would want to use CreateMock; that is a mock that enforces strict replay semantics.
When would you want strict replay?
– When you don’t want your target (System Under Test) to make calls other than those that you have expressly defined. Usually I don’t think you care, but sometimes these calls will be ‘expensive’, in the sense that they do something like make a web service call, and so we don’t want to make the call un-necessarily. Or that they cause a change of state, that is where making the call would result in incorrect behaviour of the system (e.g. A method that called CreditCardService.TakePayment() twice instead of once would probably be a ‘bad thing’). In these examples what I am really bothered about is that certain mocked operations obey strict replay semantics, rather than the whole interface.
How to use strictly mocked operations in Rhino Mocks
So if we want a mocked operation that obeys strict replay semantics we can simply use a DynamicMock and set individual operations to be restricted using Repeat.Never() or Repeat.Times(), I would also argue that this will result in much more expressive tests as you are expressly saying what operations should not be called rather than hiding this in the type of mock created.
I am not saying that a strictly mocked interface is completely un-necessary, sometimes you know that an interface is full of methods we don’t want to call (such as a web service client), and we don’t want to have to enumerate every method. Rather you should probably think about what you want to restrict calls to.
Suggested rule of thumb:
- If the interface is to an ‘expensive’ class to call use a strictly mocked interface.
- If the interface contains methods which result in a change of state then certain methods should be strictly mocked.