Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Unit testing with HttpContext

I've become a real fan of unit testing, though I was somewhat skeptical about its use in Web apps. NUnitASP is pretty cool for testing UI, but what I really needed was a way to test classes running in the context of a Web app, not actual requests for pages.

I do some caching voodoo in POP Forums to reduce database hits. Naturally this relies on the cache of the Web app, which you don't have in a unit testing context. Bummer! After some searching and link hopping I got to this article by Steve Padfield. Bam! That's what I needed. I only needed to make it work in .NET v2.

After some messing around, I arrived at this:

TextWriter tw = new StringWriter();
HttpWorkerRequest wr = new SimpleWorkerRequest("/webapp", "c:\\inetpub\\wwwroot\\webapp\\", "default.aspx", "", tw);
HttpContext.Current = new HttpContext(wr);

Pop that code in any test that will call a class that needs a non-null HttpContext. Works like a champ, and life is grand. Now if I can only get the damn tests, or the assembly being tested, to see my config settings.

11 Comments

  • Hi there,

    I'm just having a little trouble with this - trying to get the example from Steve Padfield's article working.

    Have put your line in: HttpWorkerRequest wr = new SimpleWorkerRequest("/webapp", "c:\\inetpub\\wwwroot\\webapp\\", "default.aspx", "", tw);



    ...but get this exception:

    System.Web.HttpException : Invalid use of SimpleWorkerRequest constructor. Application path cannot be overridden in this context. Please use SimpleWorkerRequest constructor that does not override the application path.



    Can't find anything on google about it - - did you see this when you were trying things out?

    Any ideas very gratefully received!

    Thanks

    S

  • My example was on v2 of the framework, the alpha (May build). I don't think the current versions have the same overload, and as such you'd need to use Steve's code.

  • As far as I can tell, this has extremely limited capabilities. Namely, an HttpRuntime is never created, which renders all but basic unit testing useless.

  • Useless? If I can store things in the cache, the only thing I've encountered that I need, then it's not useless at all. Just because you don't see a use for it doesn't mean other people might not.

  • Thanks this was very useful to me, needed to test my cache provider, this works nice :)

    Cheers
    Stefan

  • You can also access the web cache via HttpRuntime.Cache. Have a look at thisd article:

    http://weblogs.asp.net/pjohnson/archive/2006/02/06/437559.aspx

  • So true... I learned that about a year later, and it really makes a huge difference.

  • The only caveat emptorium is that if you go that route you can't go the route of using the built in .net test deployment infrastructure. Means you also have to dynamically build all the controls you are interested in which means also creating an instance of the ControlAdapter which means calling a protected RenderControl with a mock class . . .
    ad infinitum?
    yak shavings?

  • Thanks so much. worked a treat.

  • Worked great, but what if I want to create a context that has the IsSecureConnection property set to true? I need to fake out a secure HTTPS connection to test a code path.

  • Hi Jeff,
    I am using .net 3.5 framework, your code works fine, when i want to use caching however, when i try to access currentcontext session, it is null.
    Cant we use the code for accessing session?

Comments have been disabled for this content.