Can I use Moq with MvcContrib.TestHelper?

Question

I'm working on my first ASP .NET MVC project and prior to this moment I've only used Rhino.Mocks for desktop applications.

It's been a while so I decided to find out what's used in the field now.
After reading some praise for Moq, I decided to go with it.
(I love what some may call lambda mis- and overuse).

However I also heard praise for MvcContrib TestHelper framework which seems to have a dependency on Rhino.Mocks.

I need to know whether TestHelper imposes using Rhino.Mocks on me. I wouldn't want to mix two different mocking frameworks in my tests so in case TestHelper is Rhino-specific, I'll have to decide either to

• switch to Rhino.Mocks for the sake of TestHelper (sad but likely);
• abandon TestHelper for the sake of using Moq (unlikely).

I really hope TestHelper is independent of Rhino.Mocks in its public APIs but I'm not 100% sure.
Can someone (dis)confirm it?

Answer 1

I need to know whether TestHelper imposes using Rhino.Mocks on me

Yes, it does impose you to use Rhino Mocks. All the properties such as Request, Response, Session, HttpContext, ... on the TestHelperBuilder class are stubbed with Rhino Mocks and are waiting for you to write expectations on them.

Answer 2

I'm not sure when this was changed, but the TestControllerBuilder now takes an optional IMockFactory<T> argument. The problem I found with this is that if you don't pass one in, it defaults first to RhinoMocks and then to Moq, both as proxies. If you're using StructureMap, as I am, it will always use RhinoMocks. I really wish there were a flag of some sort to tell the TestControllerBuilder which one to use.

To force the builder to use Moq, you can pass in a new IMockFactory<T> class that reflects back into Moq. Internally, MvcContrib has a class that does this perfectly, but it is not publicly accessible. I'm not sure why they didn't expose it.

Instead of creating my own implementation of IMockFactory<T>, I chose to dig into the MvcContrib code and copy/pasta the MoqFactory and MoqProxy classes into my own solution and pass them into the TestControllerBuilder. It feels really dirty, but it gets the job done and lets me use Moq to my heart's content.