Unable to view response headers in unit test

Question

I have a unit test for an Http handler. In it, I create an HttpResponse object and pass it to one of the methods of the Http handler.

One of my tests is trying to verify that the response headers are set correctly:

 Assert.AreEqual( "gzip", response.Headers["Content-Encoding"]); 

However, the Headers property throws a PlatformNotSupportedException with the message "This operation requires IIS pipeline integrated mode .

The strange thing is, as I understand it, this exception is related to the response headers - without reading them. I use TDD, so I do not set the headers anywhere (yet), but still I get an exception.

Why am I getting this exception and is there a good or better way for unit test response headers?

Answer 1

From the Response.Headers documentation :

Note

The Headers property is supported only with the integrated IIS 7.0 mode pipeline and at least the .NET Framework 3.0. When you try to access the property of the headers, and any of these two conditions are not met, PlatformNotSupportedException is thrown.

Basically, you cannot even access it if you are not working with these conditions.

If I were you, I would create a constructor for your handler that takes an HttpContextBase object and use the layout to verify the headers are correct.

Answer 2

I'm not sure about the receipt, but my hunch is that you were just out of luck. On the subject of how unit test response headers. OK...

HttpContext and all its evil calves are a constant problem with TDD. They want IIS to be around, they are sealed so you can expand or mock them. Evil Evil Evil. What we usually do with these small jerks is to write our own shell with an interface for them, for example, say IHttpContext. Then you have your own HttpContext and delegate all calls. Then in your application everyone uses the interface. This fixes your problem when interacting with Microsoft private classes, because you can substitute layouts or stubs or something else.

How to check the actual specific httpContext (or response or request) I would suggest you do not need. Microsoft should be responsible for testing its own classes. While you are testing your own interaction with him, you should be hunky-dory