| Pros |
Cons |
Comments |
|
NMock2
|
Open source and free.
Expressive and easy-to-learn syntax.
Clear internal errors (supports custom messages as well).
Supports partial mocks.
Very fast.
|
Heavily relies on Dependency Injection pattern.
Type unsafe: expectations are string based.
Cannot mock non-virtual, non-abstract and static methods, cannot mock sealed classes and private interfaces.
Does not support recursive mocks [Update: or maybe it does - see comments].
|
With extension methods of C#3, one can easily extend NMock2 to
be type safe, at least for simple scenarios.
String based expectations is a deliberate choice - the team believes it gives you more power - and to make our lives easier, they made some terrific contribution. They wrote an open source Resharper plugin to help us writing all those strings.
One consequence of using string based expectations is that NMock2 is very fast as it doesn't parse expression trees at runtime.
|
Rhino Mocks
|
Open sourse and free.
Type safe.
Advanced features: supports recursive mocks and partial mocks.
|
Heavily relies on Dependency Injection pattern.
Cannot mock non-virtual, non-abstract and static methods, cannot mock sealed classes and private interfaces.
Poor intellisense experience, all RM methods just appear in any call to any object in a test.
|
Intellisense is polluted because RM returns the actual <T> from its GenerateMock and other calls, but in order to allow calling Expect, Stub and other methods, RM does so by introducing extension methods on any T.
A lot will be changed with RM 4.0 which will break backwards compatibility and presumably make the API much easier to use.
|
Moq
|
Open source and free.
Expressive and easy-to-learn syntax.
Type safe.
Advanced features: supports recursive mocks, partial mocks. |
Heavily relies on Dependency Injection pattern.
Cannot mock non-virtual, non-abstract and static methods, cannot mock sealed classes and private interfaces.
Need to use mock.Object property if we pass the mocked interface/class over.
|
Moq
is the youngest framework, bereft of the "legacy" burden of
record/replay model. This makes it pretty straightforward and
friendly, and a lot of work is being done to support and enhance the
clear API.
In order to keep clean intellisense, Moq
separates between mocked objects and expectation builder objects -
that's why you need this Object property on a mocked instance.
|
Isolator
|
Does not rely on Dependency Injection pattern.
Expressive and easy-to-learn syntax.
Type safe.
Advanced features: supports recursive mocks, partial mocks.
Überadvanced features: can mock static methods, sealed and private classes.
|
Not open source and not free.
Does not support custom error messages in expectations.
Is the slowest mocking framework.
|
Isolator is the most powerful mocking framework, and sometimes its power is (unfairly?) considered as its main weakness.
Mocking static methods etc is possible because it uses CLR profiler to intercept the calls. And even though it seemed not possible, Typemock guys went an extra mile and provided support for mocking mscorlib - DateTime.Now and File.ReadAllText(), perhaps more to follow. Awesome.
|
Moles
|
Free.
Does not rely on Dependency Injection pattern.
Type safe.
Advanced features: supports recursive mocks, partial mocks.
Überadvanced features: can mock static methods, sealed and private classes.
|
Not open source and still in a very deep beta (current version is 0.16).
Cannot be used without Pex.
A bit cumbersome syntax.
Mocks need to be regenerated each time you change the system under test.
|
Moles is designed to suppot a "parametrized unit tests generator" called Pex, which purports to change the face of unit testing forever: instead of creating mocks dynamically, Pex generates them at compile time.
One consequence of static generation is that mocks work extremely fast (however, notice that performance comparison was done for Stubs, not Moles).
As Isolator, Moles
uses CLR profiler to intercept method calls - thus being able to mock static methods, etc.
|