Unable to examine reponse headers in unit test

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

One of my tests attempts to verify that the response headers have been set correctly:

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

However, the Headers property throws a Pl开发者_运维百科atformNotSupportedException with the message "This operation requires IIS integrated pipeline mode".

The strange thing is that as I understand it, that exception is related to setting reponse headers - not reading them. I'm using TDD, so I don't set the headers anywhere (yet), but still I'm getting the exception.

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

---

From the Response.Headers documentation:

Remarks

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

Basically you can't even attempt to access it unless you're running with those conditions.

If I were you, I would create a constructor for your Handler that accepts an HttpContextBase object and use a mock in order to test your headers properly.

---

Im not sure about the get, but my hunch is your just out of luck. On the question of how to unit test response headers. well...

HttpContext and all its evil spawn are a constant problem with TDD. They want IIS to be around, they are sealed so you can extend or mock them. Evil Evil Evil. What we typically do with these little jerks is write our own wrapper with an interface for them like say IHttpContext. Then you just have your own HttpContext and delegate all the calls to it. Then in your app everyone uses the interface. This fixes your problem with interacting with Microsofts sealed classes because you can subsititute mocks or stubs or whatever.

As for how to test the actual concrete httpContext (or response or request) I would suggest you don't need to. Microsoft should be responsible for testing their own classes. As long as you test your own interaction with it, you should be hunky-dory