Posted about 4 years ago on March 13, 2010
My friend Jon is starting a training course in an effort to quickly bring developers up to speed on test driven development. As part of this effort, he has developed a unit test suite aimed at helping folks understand Rhino Mocks, a popular testing tool. After looking through the tests and seeing a lot of the Rhino API that I wasn’t familiar with, I wondered if there were similar undiscovered nooks in my favorite mocking framework: Moq.
After getting permission, I took his tests that use Rhino Mocks and implemented them with Moq. It was a great exercise for not only learning the two APIs, but also for getting a side by side comparison of the frameworks. The differences in most cases are subtle, and ultimately I found the choice between each to be a matter of taste.
Points of Interest
Mocks & Stubs?
I’m in agreement with Jon that the differences between mocks and stubs are mostly semantic, and are best reserved for academic discussions. I called all the variables in my tests “mock” because the class for creating mocks and stubs with Moq is “Mock”.
The reason I am such a fan of Moq is that the API “surface” is minimalistic. The methods I want to use most often are within clear sight and meaningful. There’s not a lot of extra jargon and noise that I have to think about. The methods that I use 20% of the time are tucked away in a manner that is still discoverable, but yet hidden enough to give me a signal that they’re not the first path I should choose.
When I want to create a mock with Moq I have one choice:
With Rhino I have several choices:
The more decisions I’m forced to make, the more disruptive the API becomes.
Jargon Watch & API Clarity
A few examples of pros/cons of the APIs
Creating a mock of a concrete class with virtual methods
…in Rhino Mocks:
The simplicity of Moq’s API shines. (Replay?*)
*Replay is a concept that was prevalent in prior versions of Rhino Mocks and it continues to necessitate appearances. The record/replay syntax is still available for backward compatibility, which adds to the verbosity of the API. Read more about record/replay.
Finding the arguments passed to a stubbed method
…in Rhino Mocks:
I prefer the Rhino syntax in this case. The concept of a “callback” is clear enough, but it is not clear that I should be using it to perform checks on passed arguments.
There are some features that are exclusive to the current versions of the libraries:
Rhino Mocks provides full support for methods with Ref arguments. Moq does not seem to. (I have an ignored failing test in my code. If you know how to make it pass please let me know!)
Mocking Protected Methods
Moq provides built-in support for mocking protected methods. You can still test protected methods with Rhino mocks, but you’ll have to write some reflection code to do so.
I favor the style and feel of the Moq API for some of the reasons described above, but as they say: “To each his own!” Hopefully you’ll find the side by side comparison helpful in determining your preferred mocking framework.
Have I missed anything? Please let me know if I’ve misrepresented or missed critical information that would help to clarify this comparison.