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

Question

There are lots of mocking frameworks out there for .Net some of them have been superseded by others that are better in everyway. However that still leaves many mocking frameworks that have different styles of usage.

The time it takes to learn all of them well enough to decide witch 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 by asking about the project and myself to help decide on the best mocking framework to use in a given case?

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.

Is there yet a useful vocabulary to use when comparing the styles of mocking frameworks?

(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 Jave)

Summary so far:

• If you need to mock static method, or none virtual methods then the only reasonable option is TypeMock, however it is not free and does not drive you towards a good design.
• Rhino Mocks is a very good option if you are doing TDD, .e.g the objects you wish to mock implement interfaces. At present it seems to be the "market leader"
• Moq (introduction) should be considered if you are using .NET 3.5 Moq may be againing on Rhino Mocks for new projects

What have I missed from this summary?

So what drives the choose between Rhino Mocks and Moq, if you are using .NET 3.5?

---

see also:

• What c# mocking framework to use?
• What are the capabilities of Moq and Rhino.mocks?
• What are the real-world pros and cons of each of the major mocking frameworks?

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

Answer 1

RhinoMock is pretty much the state-of-the art mocking framework for .NET. Can't go wrong with it. I guess you can view its "style" as a "Jack of all trades" if you so wish.

From their web site:

What does Rhino Mocks offer?

• Explicit record & replay model for expectations.
• Natural Arrange, Act, Assert syntax
• Support for .Net 2.0 and .Net 3.5
• Working with strongly typed mocks.
• Setting actions on methods, return spesific value, or throw an exception.
• Expectations based on:
  • Arguments matching
  • Constraints matching
  • Custom callback to verify the expected arguments using your own code

Answer 2

I prefer Moq for .NET 3.5 projects. It is simple to use and, in my experience, it helps to produce clean and clear unit tests.

There's no technical reason why you can't use more than one mocking framework on the same project. Sure, it's nice to standardize, but some tests may lend themselves better to some frameworks.

HTH, Kent

Answer 3

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.

Answer 4

Disclaimer – I work for Typemock

I disagree with "Typemock does not drive you to good design". It is you, the developer that drives a good or bad design, not the tool that you use. Get the tool that gets the job done, and make you productive, but the responsibility of good design is your own. If you think that wrapping all kind of abstractions inside your code, just for testing, go for it, but you may not come up with a "good" design. It could be more complex than the design you have right now.

Answer 5

stubs looks interesting and I think it may ship with .NET V4. I don’t know witch edition of developer studio you will need to use it. At present you can download it from the above link.

Stubs is a lightweight framework for test stubs and detours in .NET that is enterily based on delegates, type safe, refactorable and source code generated. Stubs was designed support the Code Contracts runtime writter and provide a minimal overhead to the Pex white box analysis. Stubs may be used on any .NET method, including non-virtual/static methods in sealed types.

(I have posted this as an answser rathern then adding it to the quesion, as I have never used Stabs and only spend a few minutes looking at it)