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:
- 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
- Ordered behaviour testing – can specify the order that the SUT should perform certain actions, can nest different groupings of ordered and unordered behaviours.
- 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.
- No need to create the mock/stub – Created dynamically within the test, will save a significant amount of time
- Decoupling of tests – by not using a single hand coded mock we will avoid coupling tests together by sharing a single mock.
- Help encourage best practice – hand coded mocks are probably easier to get wrong than framework mocks.
- Rhino Mocks is free to use and is simply a dll.
- Can work side-by-side with other frameworks and/or hand written mocks.
- Mocking of classes – need to look more at this.
- 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.
- Rhino Mocks is currently developed by a single person (I believe) this may have an impact on the long term support of this tooling.
- 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!