Best practices for HttpContext and testable controlers in ASP.Net MVC

Question

Update:

Based on a couple of the answers I have received, I just want to make clear that I am well aware how to go about mocking HttpContext using a mocking framework. I am more interested knowing what the pros and cons of mocking HttpContext are when compared to using wrapper classes around HttpContext.

---

I'm looking for opinions on how to deal with HttpContext when building testable controllers in ASP.Net MVC. After reading up on it there seems to be two schools of thought - either build off of HttpContextBase and use a mocking framework to generate the needed stubs/mocks for your unit testing or build agnostic wrapper classes around the areas of HttpContext which you intend to use.

Right now I am leaning towards building off of HttpContextBase. It seems like it is both the faster development process and easier to maintain as you don't have to spend time developing and maintaining additional wrapper classes. I can see how the wrapper classes might be beneficial as they abstract away the underlying implementation and keep the controller's context separate from the request - but I'm not sure if this is worth the extra overhead to setup and maintain.

What do you feel are the pros and cons between these two approaches and when would you choose one over the other? Are there certain types of development that lend itself to one of the solutions more so than the other?

As this seems like a common issue most teams who are unit testing and using ASP.Net MVC have to deal with, how would you or have you gone about handling this issue? If you have addressed this issue, how did your solution work and what would you do differently now?

Thanks!

Answer 1

For testing I use Rhino.Mocks. To set up the HttpContext in the controller, I simply mocked it. So my system under test (or sut) is something like:

            Controller controllerBase = sut as Controller;

I then mock out the controller context, and set up the context on the controller context to return the mock of the HttpContextBase class (as I mentioned above). My code looks something like:

controllerContext = AMockOf<ControllerContext>();

// Add the test HttpContextBase to the controller context
HttpContextBase httpContextBase = SetUpTestHttpContext();
WhenThe(controllerContext).IsAskedForIts(x =>x.HttpContext).Return(httpContextBase).Repeat.Any();

For other objects I sometimes use fakes as well.

Answer 2

Maybe this thread also helps you:

http://stackoverflow.com/questions/32640/mocking-asp-net-mvc-controller-context

Answer 3

I'm leaning towards HttpContextBase. Mainly because I think it was invented for just this reason: testability. And why reinvent the wheel when there's an acceptable solution already out there.

If you put a lot of effort into your wrapper classes around HttpContext, you'd end up with something very similar to HttpContextBase...