Geek Answers Handbook

Why mock an HttpContext if it can be built?

I always faked / ridiculed / drowned out the HttpContext somehow in ASP.NET (much easier in ASP.NET MVC / MonoRail).

But I see that HttpContext itself can be built easily, literally with a 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 include this code in something like this, it should work fine, and perhaps we can even make ASPX using this:

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

So the questions are:

  • Reasons why this should NOT be done.
  • Reasons why this MUST be done.
  • Why is it not widely used (in fact, I do not remember any reports about this).

I remember one post in which Phill Haack built an HttpContext using Reflection hacks.
But it doesn't seem to be necessary.

Cheers
Dmitry.

+7
asp.net-mvc testing mocking
source share
3 answers

This is great for very simple testing, but how would you unit test a component that uses HttpRequest.Files? As far as I know, there are no public APIs that allow you to point this to SimpleWorkerRequest. Even if you can find a place where you can set the HttpFileCollection property, note that its constructor is internal, so you cannot even create an instance of this type.

HttpRequest.Files is not alone in this regard, and in fact there are probably many more things you cannot test with the current HttpContext implementation than you can verify. Here abstractions really come in handy.

+5
source

There are several scenarios here.

Scenario One: You are testing a device. you have something small, like a class that controls cache access and that explicitly calls HttpContent.Cache. In this case, make fun of the context so you can see which calls are being made and whether they work as you expect.

Scenario 2. You conduct an integration test where you try to test something big, for example, creating a complex page. In this case, give it the actual HttpContent object as you found it. Your integration test better simulates real-time execution.

+2
source

It might work, but ...

  • Firstly, I see several ways that can be different in environments.
  • Secondly, does he need something like installing IIS?
  • How long does it take to create it? If I have 100 tests that need it, and it takes 1 second, then this means that my test run in about a minute or longer, and this leads to the fact that developers will test less.
  • How easily you can fool / configure cache, request, etc. to create a test script?

Lubrication / lowering is probably easier.

EDIT

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

This can give a better idea of ​​what is happening in the work.

Found an article that might also be useful: ASP.NET CreateApplicationHost / SimpleWorkerRequest API Hole

This actually illustrates well that we need to understand what is happening in this object before applying them, and this takes time. The meaning seems simpler.

0
source

More articles:


All Articles