NUnit and HttpContext

  • Thread starter Thread starter JahMic
  • Start date Start date
J

JahMic

I recently took on the unenviable task of using the HttpContext object
in my unit tests, as any body who has tried this before knows it is
not so easy. The three main approaches I have found are: 1) Making a
mock object, 2) Faking a Context via SimpleWorkerRequest, and 3)
Creating your own host environment ala CreateApplicationHost.

I didn't like the first approach, because their might be some
variation between a mock object and the real thing. That reduces a lot
of the power of unit testing. (...thoughts?) The Second approach is
fairly well publicized over the web but seems to only good for .NET
1.x. Trying some of the projects unchanged in a 2.0 environment
simply does not work, as the WorkerRequest seems to want to work out
of an actual host environment.

The third approach is promising but I'm still having some problems
getting the HttpContext into the unit tests. A good article on this
approach:
http://hyperthink.net/blog/CommentView,guid,271632d2-07e3-41af-9e58-9a7e25348b8c.aspx
In it, he exposes the HttpContext by a call to:
System.Runtime.Remoting.Messaging.CallContext.SetData("HttpContext",
request).
Pretty cool, except when the execution returns back at the unit test
call, HttpContext.Current is still null. Thoughts?

To either return the HttpContext in a call or expose it as a public
field causes NUnit to throw an exception that it is not
serializable... Serializable??? I don't particularly if it's
serialized or not... Marking the class as [Serializable] does not
help and I'm now at a loss on how to get through this. Thoughts?

Any help, much appreciated.

J
 
I recently took on the unenviable task of using the HttpContext object
Click to expand...
[snip]

There's very few who think of this, but in fact a Singleton class will
in a Web Application basically work as the Application object in the
matters that it'll "never die"...
If you need to have objects that exists on the cross of http calls
(statefulness like Session, HttpContext and Application) you CAN in
fact use a Singleton class since that "one instance object" will NOT
be destroyed and recreated before the application is killed...
:)

..t
 
[snip]

There's very few who think of this, but in fact a Singleton class will
in a Web Application basically work as the Application object in the
matters that it'll "never die"...
If you need to have objects that exists on the cross of http calls
(statefulness like Session, HttpContext and Application) you CAN in
fact use a Singleton class since that "one instance object" will NOT
be destroyed and recreated before the application is killed...
:)

.t

--http://ajaxwidgets.com
Free ASP.NET Ajax Widgets NOW!
Click to expand...

Hi Thomas,

Sounds promising but I tried to think of several ways a Singleton
class could help and nothing seemed to pan out. Could you elaborate
on your thoughts a bit more?

Also, it seems the problem with CreateApplicationHost approach is that
it creates a seperate domain space where remoting gets involved.
 
Back
Top