Why static mocks for unit testing?

Feb 11, 2010 at 5:26 PM

Wondering why Training Management application uses static mocks (Contoso.TrainingManagement.Mocks) + TypeMock Isolator. Why not Rhino Mocks or any other mocking framework? Has anybody done this? Any examples?




Feb 11, 2010 at 6:16 PM

Hi Stan,

We looked at a number of different mocking frameworks including Rhino Mocks.  None of the conventional mocking frameworks can substitute implementations for static methods or deal with private constructors or sealed types.  There are a lot of these in the SharePonit APIs, and for thse cases, we use TypeMock to replace the implementation. 

In terms of the manual mocks, the cases were simple enough and we felt that we didn't need to introduce another mocking framework for the amount of mocking/stubbing we were doing.  We went with manual mocks to keep it simpler.

In the 2010 release we are using Moles which is an alternative to TypeMock.  TypeMock continues to be a great choice, we just wanted to explore other areas as well. 



Feb 12, 2010 at 1:56 PM


There is an interesting problem if I want to use Rhino mocks instead of static (manual) ones:

MockRepository mocks = new MockRepository();

IProfileRepository mock = mocks.StrictMock<IProfileRepository>();

I can register (swap) real repository with mock:


However, in the presenter when the repository is instantiated, essentially it is


and here is where the problem comes in - Rhino mocks wants to control mock itself and it blows up with "no parameterless constructor defined".

One way of solving it as somebody pointed out, is the classical IoC/DI way - passing IProfileRepository to constructor, but that is a quick a bit of rework..