Menu
There are lots of mocking frameworks out there for .Net. There is no clear winner that has superseded the others in every way. The leading mocking frameworks also have many different styles of usage.
The time it takes to learn all of the mocking frameworks well enough to decide which to use is unreasonable. I don’t believe that we have yet reached a stage that we can talk about the best mocking framework. So what questions should I be asking, both about the project, and about myself, to help decide on the best mocking framework to use, in a given case?
It would also be useful to know why you chose the mocking framework you are currently using and if you are still happy with that choice.
Is there a useful vocabulary to use when comparing the styles of mocking frameworks?
(Note: I have limited this question to .Net as Java does not have attributes or lambda expression, so I hope the mocking frameworks can be better for .Net then Java)
Summary so far:
What have I missed from this summary?
So what drives the choice between Rhino Mocks and Moq, if you are using .NET 3.5?
see also:
“What should I consider when choosing a dependency injection framework for .NET?” may also be of interest as it asks the “other side” of the question.
873
What is a mocking framework? Mocking frameworks are used to generate replacement objects like Stubs and Mocks. Mocking frameworks complement unit testing frameworks by isolating dependencies but are not substitutes for unit testing frameworks.
Only use a mock (or test double) “when testing things that cross the dependency inversion boundaries of the system” (per Bob Martin). If I truly need a test double, I go to the highest level in the class hierarchy diagram above that will get the job done. In other words, don't use a mock if a spy will do.
The benefits of a mocking framework are: Easier (subjective, but after a while you will not write hand written implementations) Less Code (frameworks allow you to create a mock in a matter of lines, rather than full class declarations) Follows DRY (you won't end up repeating mock implementations)
Mocking is generally useful during unit testing so that external dependencies are no longer a constraint to the unit under test. Often those dependencies may themselves be under development. Without mocking, if a test case fails, it will be hard to know if the failure is due to our code unit or due to dependencies.
So what questions should I by asking about the project and myself to help decide on the best mocking framework to use in a given case?
The questions you should be asking about the project is: Has the project been developed with the SOLID principles, or not? Is this a project that has loose coupling and high cohesion? Have good OO principles been utilized in building the project? Is a Dependency Injection container being utilized? Has the system been coded in a Design by Contract method (utilizing Interfaces thoroughly)?
If you answer yes to these questions, then you can utilize a mocking framework like RhinoMocks, which is what some would call an "opinionated" framework. RhinoMocks, and some other mocking frameworks, have very strong opinions about how a system should be designed in order for objects to be mocked. A framework like RhinoMocks expects your project to be designed a certain way. Mocking is certainly a lot easier with RhinoMocks when you've built your code the right way (no sealed classes, no statics, heavy use of interfaces, virtual on class methods, etc.)
If you answer no to those questions, or if you're working on a legacy system with a lot of highly coupled classes, then your only choice is going to be TypeMock, which can mock just about anything.
It would also be useful to know why you choose the mocking framework you are currently using and if you are still happy with that choose.
I chose RhinoMocks because at the time (3+ years ago) it was clearly the most mature mocking framework with the most features. I've stayed with it because it has evolved in away that makes my life much easier (the advent of the AutoMocking container being a gigantic step toward efficiency).
What I like about RhinoMocks, other than the feature set and ease of use, is that it guides me toward a better design in my code. I am not a perfect programmer, and I am going to make mistakes in design. But tools like RhinoMocks and NHibernate help guide me toward a better design, because when I do make mistakes and create poor design, these tools become painful to work with. NHibernate, for instance, is painful to work with if you have a bad database design. RhinoMocks is very painful to work with if you have a poor class design, aren't using interfaces, aren't using IoC... etc.
I like RhinoMocks because it ultimately helps me be a better developer, and not just because I'm testing my code, but because I'm shaping my code - designing it - in a better manner.
121
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
