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.

So far I have used RhinoMocks and Moq. Moq is currently my favourite due to its simplicity which is currently all I need. RhinoMocks is pretty powerful but I have never been in the position to fully tap into it.

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.

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.

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.

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.

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