Comparing and Contrasting Moq and Rhino Mocks

Posted over 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.

You can find Jon’s tests here, and mine here.

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”.

API Surface

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:

Capture

With Rhino I have several choices:

rhinooptions

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:

Capture

In Moq:

Capture

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:

Capture

In Moq:

Capture

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.

Feature Parity

There are some features that are exclusive to the current versions of the libraries:

Ref Arguments

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.

Conclusion

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.

Comments

TrueWill writes...

Nice article!

For finding the arguments passed to a stubbed method in Moq, you can simply specify the argument to match or use the It.Is... methods. See Introduction to Moq under Matching Arguments. You could return a specific value or use Verify (see the example "Verify setter with an argument matcher" in the above link).

Moq also supports both out and ref arguments; see Methods in the above link.

March 15, 2010

New Comment