Should we use a mocking framework?

At the moment I’m tasked with investigating mocking frameworks. Currently we are using hand-written mocks/stubs, and I need to see what mocking frameworks are out there and what benefits they would bring. So far I’ve been focussing on Rhino Mocks and have looked briefly at TypeMock. Initial findings (based around Rhino Mocks) are:


  1. Behaviour testing – our current mocks/stubs only allow for state testing so you can test the final result/state of the System Under Test (SUT) but you can’t verify any behaviour it performed. Where there is a requirement for the SUT to make a call to an external dependency (for example) we have no way of testing this
  2. Ordered behaviour testing – can specify the order that the SUT should perform certain actions, can nest different groupings of ordered and unordered behaviours.
  3. Event handling – although we have no immediate need for this as the code we are TDDing (is that a word?) does not use events, at some point we might use events, particularly for UI testing.
  4. No need to create the mock/stub – Created dynamically within the test, will save a significant amount of time
  5. Decoupling of tests – by not using a single hand coded mock we will avoid coupling tests together by sharing a single mock.
  6. Help encourage best practice – hand coded mocks are probably easier to get wrong than framework mocks.
  7. Rhino Mocks is free to use and is simply a dll.
  8. Can work side-by-side with other frameworks and/or hand written mocks.
  9. Mocking of classes – need to look more at this.


  1. Require developers to learn how to use the framework. I would say that from scratch it would probably be easier to learn how to use Rhino Mocks than to learn how to use our hand written mocks.
  2. Rhino Mocks is currently developed by a single person (I believe) this may have an impact on the long term support of this tooling.
  3. Given enough time we could probably do most (everything) that a framework gives us, however why re-invent the wheel? Every new functionality we need from a hand written mock needs to be thought about – most of this thinking already done in the framework

Any comments or further points are welcomed!


About Alex McMahon

I am a software developer, interested in .net, agile, I've previously specialised with .net 3.0 technologies like WCF, whereas now I am trying to specialise in agile development and best practice and patterns. I am obsessed with looking at the latest technologies, tools, and methods, and trying them out. I am currently employed by Rockwell Collins in the UK.
This entry was posted in mocks, TDD, testing. Bookmark the permalink.

2 Responses to Should we use a mocking framework?

  1. mdenomy says:

    Mocking frameworks definitely take some time for developers to get the hang of, but I think once your team gets the hang of them you will find them very useful.

    I have been using NMock and NMock2 for a few years.

    I find mocking, and TDD in general, really help the developer decouple the code by making clear distinctions on what the dependencies are on an class/object under test.

    In the case on NMock/NMock2, only interfaces can be mocked (can’t mock a class) which also helps reinforce loose-coupling. Sometimes NMocks requirement to only mock interfaces can be a pain, so I would be curious to see how the other frameworks match up. I believe with TypeMock it is possible to mock classes.

    Different behavior can be introduced into the mocked objects (using expectations and stubs) on NMock. NMock2 supports a set of built-in expectations and actions, but it is possible to extend this functionality if desired using Actions and Matchers. Our team is able to get by with almost all built-in functionality, but have developed some custom actions/matchers for particularly tricky tasks.

    My experience has been that maintaining hand-written mocks/simulators is a difficult task and in the long run become unwieldy and get discarded. Once the team comes up to speed on the mocking framework syntax it becomes very easy to understand the desired behavior directly from the unit test.

    I would recommend trying a few and seeing how the team responds. Starting out can be tough, but stick with it and I think you’ll be happy with the results.

  2. Pingback: Mocks: What and why? A directed ramble « Our Craft

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s