Why mock HttpContext if it can be constructed?

Question

Hi,

I have always been faking/mocking/stubbing HttpContext somehow in ASP.NET (much easier in ASP.NET MVC/MonoRail).

But I can see that HttpContext itself can be constructed easily, literally with couple of lines of code.

var tw = new StringWriter();
var workerReq = new SimpleWorkerRequest("/webapp", @"c:\here\there\wwwroot", "page.aspx", tw);
var context = new HtpContext(workerReq);

If we'll wrap this code into something like this it should work fine, and probably we can even render ASPX using that:

using(Simulate.HttpContext()) {
  HttpContext.Current.BlaBla;
}

So the questions are:

1. Reasons why it should NOT be done.
2. Reasons why it SHOULD be done.
3. Why it is not widely used (in fact I do not remember ANY posts about it).

I remember one post where Phill Haack constructed HttpContext using Reflection hacks.
But it seems it is just not needed.

Cheers,
Dmitriy.

Answer 1

There's a couple of scenarios to consider.

Scenario One: You're unit testing. you have something small, like a class that manages access to the cache, and which calls HttpContent.Cache explicitly. In this case, mock the context so you can see what calls are being made, and whether they're working the wy you expect.

Scenario Two: You're doing an integration test, where you're trying to test something large like the generation of a complex page. In this case, give it the real HttpContent object the way you've found. Your integration test will better simulate the real runtime.

Answer 2

It's fine for doing very simple testing, but how would you unit test a component which uses HttpRequest.Files? As far as I know there are no public APIs to allow you to specify this on SimpleWorkerRequest. Even if you could find a location where you could set an HttpFileCollection property, note that its constructor is internal, so you can't even create an instance of that type.

HttpRequest.Files is not alone in this regard, and in fact there are probably vastly more things you can't test with the current HttpContext implementation than you can test. This is where abstractions really come in handy.

Answer 3

That might work, but...

• Firstly I see some paths, that might be different in environments.
• Secondly does it need something like IIS installed?
• How much time it takes to create it? If I have 100 tests that need it and it takes 1 sec, then that means my test run about minute or more longer and it leads to developers running tests less.
• How easily you can mock/setup Cache, Request etc for creating test scenario?

Mocking/stubbing is probably easier.

EDIT

Found some source code for HttpContext and SimpleWorkerRequest in Mono project:

• SimpleWorkerRequest.cs
• HttpContext.cs

Those can give better insight what is happening in creation.

Found an article what might be helpful as well: ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

That actually illustrates nicely that we need to understand what is happening in those object before applying them and it takes time. Mocking seems easier.