For my ASP.NET MVC3 (new) development, I don’t want to create a dependency on MvcContrib TestHelper (and thus Rhino Mocks) unless it is providing significant value. So I’m seeking to understand the current status of this helper.
The documentation says that TestHelper produces fakes for the following controller dependencies:
- HttpContext
- HttpRequest
- HttpResponse
- HttpSession
- Form
- TempData
- QueryString
- ApplicationPath
- PathInfo
For MVC1 and MVC2 I can see why this was so helpful. But MVC3 started to introduce improved test “seams” which may have made TestHelper less pertinent. For example, the MVC3 Request and Response controller properties were designed specifically to be isolateable/injectable versions of HttpRequest and HttpResponse.
As I’m still exploring testability advancements in MVC3, I’d like to know how many of the other dependencies listed above have received improved isolation (or injectability) in MVC3. I’d also love to see samples of code showing what it looks like in MVC3 to create tests with fakes (stubs / mocks) for the above dependencies WITH and WITHOUT using TestHelper.
If the differences in test-writing with and without TestHelper are sufficiently marginal, then I’d prefer to forego TestHelper…which means I am then free to choose whatever isolation framework I like (MOQ or NSubstitute).
Ultimately I would be surprised to learn the MVC3 release had taken specific improved testability steps for HttpRequest and HttpResponse, but not for the other above listed dependency issues. I’m hoping someone can give a break-down of how the above items are isolated without using TestHelper.
MVC didn’t introduce absolutely anything new in respect to the objects you have listed in your question in terms of unit testabaility. They were abstractions in ASP.NET MVC 1 and 2 and are abstractions in ASP.NET MVC 3. This allows you to unit test your controller actions and code that depends on them in isolation. But in order to do that you need to mock those dependencies. That’s where a mocking framework comes into play. Rhino Mocks is just one possible framework. MVCContrib.TestHelper provides a really nice and fluent syntax to unit test controller actions. Personally I use it all the time. It really makes the unit tests more readable and avoids cluttering them with all kind of plumbing, mocking and infrastructure code.
Check this unit test for example: https://github.com/darind/samplemvc/blob/master/tests/SampleMvc.Web.Tests/Controllers/UsersControllerTests.cs
ASP.NET MVC 3 introduced a dependency resolver and providers which allows you to inject dependencies into many other parts of the framework other than simple controllers and thus unit test those parts which previously were difficult. For example action filters.
But in terms of the actual unit test it doesn’t change anything: