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?

#.net core #asp.net core #unit testing #progaming