Along this journey, the ASP.Net MVC framework that we use has turned out to be one of the more elegant bodies of software I have used in a while, but I didn't really appreciate that until I tried testing code in it's context. The main principal at play here is that in MVC you are always using an abstraction/wrapper over the core ASP.Net classes. You don't have to use them (apparently if you are dumb or a sucker for pain) since you can always reference HttpContext.Current and do whatever you want to.
Long story short, whenever we bypassed the framework (and it's abstractions), we paid dearly. It turns out the MVC framework was designed with testability in mind, so if you go with the flow (man) you get to inherit that for free. It took a fair amount of refactoring to make sure nobody was touching ASP.Net constructs directly. Let's just say that I had to checkout 100+ files to remedy the situation.
Moral Of The Story: never reference HttpContext.Current, ever ever ever. While this ASP.Net convenience function is handy and reliable, it makes your code inherently untestable. Why? Because it can't be mocked, and if it can't be mocked, it cannot be unit tested.
So what is a coder to do? Every Controller and View has a Context (ControllerContext and ViewContext respectively). These provide accessors to an HttpContext that derives from HttpContextBase which is an Abstract and thus mockable class. So, if you want to work with the Request - ControllerContext.HttpContext.Request (or, even more conveniently the BaseController has a shortcut - HttpContext.Request). Similarly, in Views you can reference the a Session like so: ViewContext.HttpContext.Session. Neato peachy keen and a boon to testability!
So what do you need to do to fully mock the MVC application? We found all sorts of snippets of code around the intertubes that did this and that, even some attempts and a full blown mocking framework for MVC. Your mileage may vary with any of these, but at the core there are a few things you need to know. First off, you need to be able to take control of the
- HttpSession
- HttpRequest
- HttpResponse
Everything pretty much pivots around these main classes. You have some choices to make about the "how" of mocking as well. You can use Mock Objects or Stubs. Your choice depends on how much control you want over the objects themselves. We use Moq which is pretty powerful in that it can Mock almost anything and you can add dynamic behaviors to objects with relative ease. That said I like to mix in Stub (or pretend) objects that mimic real behavior. For example, I want to Mock the HttpSession, which is a pretty dumb object (not a lot of logic) but it does have a storage mechanism. By simply extending the Abstract base class, I can mimic real Session level storage.
public class MockHttpSession : HttpSessionStateBase
{
readonly Dictionary<string, object> _sessionStorage = new Dictionary<string, object>();
public override object this[string name]
{
get
{
if (_sessionStorage.ContainsKey(name))
{
return _sessionStorage[name];
}
return null;
}
set { _sessionStorage[name] = value; }
}
public override void Remove(string name)
{
if (_sessionStorage.ContainsKey(name))
{
_sessionStorage.Remove(name);
}
}
}
Then I can use a real Mock and have it leverage this Stub
var Session = new MockHttpSession(); var Context = new Mock<HttpContextBase>(); Context.Setup(ctx => ctx.Session).Returns(Session);
At test setup time, I can set variables in the session storage, and the executing code is none the wiser.
For simple property set/get you can just leverage Moq's SetupAllProperties functionality. This will mimic the basic get/set on the object so that you can get/set on them without having to create a stub or define the dynamic functionality at setup. EG:
var Cache = new Mock<HttpCachePolicybase>(); Cache.SetupAllProperties();
So what does it look like to mock everything at once? More on that in Part 2.
