What are the real-world pros and cons of each of t

Question

see also "What should I consider when choosing a mocking framework for .Net"

I'm trying to decide on a mocking framework to use on a .NET project I've recently embarked on. I'd like to speed my research on the different frameworks. I've recently read this blog post http://codevanced.net/post/Mocking-frameworks-comparison.aspx and wondered if any of the StackOverflow audience has anything to add in the way of real-world advantages and caveats to the frameworks.

Could people could list the pros/cons of the mocking frameworks they either currently use or have investigated for their own use on .NET projects. I think this would be not only a help to me to decide for my current project, but it will help others make more informed decisions when picking the correct framework for their situation. I'm not an expert on any of the frameworks but I would like to get arguments for and against the major frameworks I've come across:

• RhinoMocks
• Moq
• TypeMock Isolator
• NMock
• Moles

And other usable alternatives that I've missed. I'd also like insights from users that have switched or stopped using products because of issues.

Answer 1

We've used Rhino Mocks for more than a year now. PRO:

• easy to create the mocks
• can mock public and internal methods
• can mock interfaces or classes
• can create partial mocks (mocking only specific methods from a class)

AGAINST:

• methods must be at least internal and virtual (can mess with your architecture)
• difficult to use for property-by-property asserts, especially for collections of objects that get created inside the test scope - the constraints syntax gets complicated
• you have to be careful when the recording stops and the playback begins
• careful about what calls are being mocked (like a property call that you didn't see or a method that wasn't virtual) - the errors you may get are not very helpful

As a general note, we've found that using the mocking frameworks promotes "white box" testing (especially for unit tests). We ended up with tests that validated HOW things were done, not WHAT they were doing. They were useless for refactorings and we had to rewrite most of them.

Answer 2

I don't know Moles at all, but I'll cover the ones I know a bit about (I really need a table for this, though).

Moq

Pros

• Type-safe
• Consistent interface
• Encourages good design

Cons

• Not as full-featured as some of its competitors
  • It can't mock delegates
  • It can't do ordered expectations
  • probably other things I can't think of right now...
• Can only mock interfaces and virtual/abstract members

Rhino Mocks

Pros

• Type-safe
• Full feature set
• Encourages good design

Cons

• Confusing API. There are too many different ways to do the same things, and if you combine them in the wrong way it just doesn't work.
• Can only mock interfaces and virtual/abstract members

TypeMock Isolator

Pros

• Type-safe (AFAIR)
• Can mock anything

Cons

• Very invasive
• Potential Vendor Lock-In
• Does not encourage good design

NMock

Pros

• Encourages good design
• Works on any version of .NET (even 1.1)

Cons

• Not type-safe
• Can only mock interfaces and virtual/abstract members

Please note that particularly the advantages and disadvantages regarding TypeMock are highly controversial. I published my own take on the matter on my blog.

I started out with NMock when that was the only option back in 2003, then migrated to Rhino Mocks because of its type safety, and now use Moq because of the simpler API.

Answer 3

Like Frank and Chris, I tried RhinoMocks and switched to Moq. I haven't been disappointed. See my series of blog posts:

• Stubbing problems with Rhino Mocks
• Mocks: The Next Generation
• Mocks: The Next Generation II
• Switching to Moq

EDIT: Note that I generally do state-based testing with stubs; I seldom do behavior testing with verifiable mocks.

Answer 4

You may want to keep in mind that if you need to support a multi-language environment (e.g. VB) all of the code configurable frameworks (I can speak to Moq and RhinoMocks directly) are going to be painful given the (lack of) anonymous delegate/lambda syntax in VB. This will be more possible in Visual Studio 2010/VB 10 but will still not be comparable to the nice C# lambda syntax.

TypeMock appears to have some support for VB

Answer 5

I've not used all those frameworks, but I looked at RhinoMocks and Moq, and went with Moq because it feels more elegant and much simpler. I am using the trunk version which includes a must-have fix for the 4 argument limit imposed on callbacks in the most recent 4.0 beta release.

I especially like the default Moq behavior, which doesn't behave like a strict Mock Object failing tests when unexpected calls are made. You can configure it to do this if you want, but I find that requires me spending way too much time setting up expectations and not enough time testing.

Answer 6

I use TypeMock since I'm developing on SharePoint. As TypeMock can mock anything, it's proved a valuable resource when unit testing our SharePoint webparts, event recievers, workflows, etc.

On the downside, TypeMock can be expensive, however there is a version available which is specific for SharePoint and costs less then the full TypeMock package. I highly recommend it.

The one thing I do disagree with is this notion that TypeMock does not make you design your code very well. Often the classes I create, and overall code, are designed well. Just because I use TypeMock doesn't mean I sacrifice the quality of my design - I still practise IoC and SRP. Just because TypeMock can mock anything does't mean I write my code to reflect that ability.