2

When it comes time to test my web controllers, I have found that mocking the HttpRequestMessage object can be a pain. It's quite a cumbersome object to have to mock. I'm also not a fan of the statefulness the Request object carries into my functions.

For these reasons, I have started "ignoring" the request object and have begun using things like:

  • Implementing ParameterBindingAttributes to get specific access to the Headers I want
  • Manually creating and returning an HttpResponseMessage instead of calling this.Response.CreateResponse(...)

I have found that this makes both my code easier to read and easier to test.

That said, before I go further with this approach, I wanted to make sure there were not any explicit reasons why I shouldn't write my code like this.

  1. Is there any specific information that would be difficult to access unless I use the HttpRequestMessage intance?

  2. Is there any thing info that my manually created HttpResponseMessage will be missing because it wasn't created using the instance method CreateResponse?

  3. Is there any reason this might comeback to bite me in the future?

rysama
  • 1,674
  • 16
  • 28
  • Have you seen [this](http://stackoverflow.com/questions/21758615/why-should-i-use-ihttpactionresult-instead-of-httpresponsemessage)? – Jasen Jan 26 '16 at 04:56
  • Yes, I haven't seen anyone use IHttpActionResult in away that doesn't use the `ApiController`'s `Request` instance. I want to know why people feel it's necessary to use that `Request` object. Especially when you can just do this: `return new HttpResponseMessage(HttpStatusCode.Ok);` – rysama Jan 26 '16 at 21:40

0 Answers0