| Pros |
Cons |
Comments |
|
NMock2
|
Open source and free.
Expressive and easy to learn syntax.
Clear internal error messages, possibility to provide custom ones.
|
Needs Dependency Injection to work.
Can mock only interfaces.
No way to turn off Strict mocks.
Not type safe: expectations are string based.
|
Using extension methods of C#3, one can easily extend NMock2 to
be type safe, at least for simple scenarios.
Mocking classes (at least virtual/abstract methods) is planned. Support for nonstrict mocks is planned probably after that.
|
Rhino Mocks
|
Open sourse and free.
Type safe.
Allows both strict and nonstrict
mocks.
Can mock classes and interfaces.
Supports advanced features as recursive mocks, partial mocks, etc.
|
Needs Dependency Injection to work.
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.
Cannot provide custom error messages for failing expectations.
|
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.
The reason for being unable to mock non-virtual methods lies deep inside RM: it uses Castle Dynamic Proxy to proxy the types it needs to mock, and Dynamic Proxy cannot intercept calls to non-virtual, non-abstract methods.
|
Moq
|
Open source and free.
Type safe.
Allows both strict and nonstrict mocks.
Can mock classes and interfaces.
Supports advanced features as recursive mocks, partial mocks, etc.
Expressive and easy to learn syntax. |
Needs Dependency Injection to work.
Cannot mock non-virtual, non-abstract and static methods, cannot mock sealed classes and private interfaces.
Cannot provide custom error messages for failing expectations.
Need to use mock.Object property if we pass the mocked interface/class over.
|
Moq is the youngest framework, bereft of the "legacy" syntaxes of record/replay model etc. This makes the 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.
The reason for being unable to mock non-virtual methods is the same as for Rhino Mocks: both frameworks use Castle Dynamic Proxy to proxy the mocked types, so both suffer from the same problems. |
Typemock Isolator
|
Does not need Dependency Injection to work.
Type safe.
Allows both strict and nonstrict
mocks.
Can mock classes and interfaces.
Can mock static methods, sealed and private classes.
Expressive and easy to learn syntax. |
Not open source and only paid version avilable (no free Community Edition anymore).
Cannot mocks mscorlib types.
|
Isolator is the most powerful mocking framework, and sometimes its power is (unfairly?) considered as its main weakness.
Although I mentioned Isolator is type safe, its Reflective Mocks approach is not (so, only AAA and Natual Mocks are type safe).
Inability to mock mscorlib types might be seen as a minor imperfection (no one can do that anyway). But if the guys from Isolator emphasize that it does not require you updating the existing design, mocking mscorlib types is as important as, say, mocking static methods.
|