I have a Web API method which throws an exception in the RC of MVC4:

public FaceBookAuthenticateResult PutAuthenticate(string facebookAccessToken)       
{
   throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.Unauthorized, new Bar());
}

I would like to test this method, but how would I do that? When running in the test the Request property of the ApiController will be null. I can only assign a

new HttpRequestMessage()

to the request property which is not abstract and has no virtual methods so I cannot mock or stub it. If I do assign a HttpRequestMessage to the property the CreateResponse method will fail due to some missing state.

This was a lot easier with the generic HttpResponseMessage which has been removed going from beta to RC. Am I missing something... Everything else in MVC has interfaces or abstract classes (like the regular Controller class).

The ApiController.Request is set-able so you should be able to just set it. A request itself is easy to create and everything is fully set-able as well.

It is correct that you need to set some state to get CreateResponse to work. Here's what should allow you to get started:

request.Properties["MS_HttpConfiguration"] = configuration;

where configuration is just a default instance of the HttpConfiguration.

We do have a work item on making easy setters for these [1] but we haven't gotten to it.

Hope this helps,

Henrik

[1] http://aspnetwebstack.codeplex.com/workitem/156

Thank you, that does work, but I must say that I find it odd that there are two very different ways of achieving this in MVC controllers and Web API controllers. I think MVC has a far better API for this - as I can do something like this:

HttpContextBase context = Stub<HttpContextBase>();
context.Stub(context => context.Request).Return(Stub<HttpRequestBase>());

FooController foo = new FooController();
foo.ControllerContext = new ControllerContext(context, new RouteData(), foo);

In Web API it must be done like this:

BarController bar = new BarController();

HttpConfiguration configuration = new HttpConfiguration();
HttpRequestMessage request = new HttpRequestMessage();
bar.Request = request;
bar.Request.Properties["MS_HttpConfiguration"] = configuration;

So whats wrong with this:

• Totally different API which is confusing (even with easy setters)
• The ApiController class does have a ControllerContext property like the MVC Controller class, but setting it does not have the same semantics (actually in my case it makes no difference if it is set or not).
• Impossible to mock the HttpRequestMessage object, so when testing it is necessary to build up the entire object by hand. It would have been nice if it was an abstract base class as in MVC.

I would like to be able to do something like this:

HttpRequestMessageBase request = Stub<HttpRequestMessageBase>();
//setup the request stub

BarController bar = new BarController();
bar.ControllerContext = new HttpControllerContext(Stub<HttpConfigurationBase>(), Stub<IHttpRouteData>(), request);

Or something like it.

Why is it better to mock the HttpRequestMessage instead of just creating one and setting it's properties?

The HTTP APIs are different and while we understand that this causes some confusion the new HTTP API does have a number of benefits:

• Generally easier to work with (ex strongly typed headers, strongly type content, etc.)
• Not tied to any one particular host, so that we can host Web API on anything
• Symmetric API with the new HttpClient so you have the same programming model on both sides of the wire

Because the HTTP API is used symmetrically on the client and server you can write full in memory end-to-end tests like this:

ContactManagerApplication.ContactRepository = new SampleContactRepository();
var config = new HttpConfiguration();
WebApiConfig.Configure(config);
var server = new HttpServer(config);
var client = new HttpClient(server);
var contact = new Contact() { Name = "Test" };
var response = client.PostAsJsonAsync<Contact>("http://localhost/api/contacts", contact).Result;
var postedContact = response.Content.ReadAsAsync<Contact>().Result;
Assert.IsNotNull(postedContact);

Daniel Roth 

I guess it is a matter of ones individual coding style if you prefer mocking or creating an object using setters. Personally I would prefer mocking it as I would have a consistent style cross the request object and other mocked services + I would reduce the Web Api specific 'plumming' code I need to write in order to get the test up and running. I am sure there are others in the community who have stronger opinions on this than I have, so the point I am trying to make is that the API does not give us the choice of mocking. Which I think is a bad thing and a step down from the MVC API. I am not discussing the changes made to the Web API in genneral and I am sure you have put great efforts into creating a great API, I am just arguing that in this case I would have liked it to be more like the MVC API.

Regarding the sample test then I am sure there are many developers who would write a test like the sample you provided. There are also many who do not write end-to-end tests, but instead test the individual components of the application. I do not want to go into a Unit test discussion, but I would not want to write a test like that. What I want to do is to create an instance of the controller class (injecting dependencies in the constructor) and test one thing in each test. I genneral I find that the API very nicely supports dependency injection and think you have done a great job allowing unit tests of the controller - except for the missing abstract base classes (and I did like the generic HttpResponseMessage but I am sure you had good reasons to remove that).

So just to sum up what I am trying to say is that I cannot think of one good reason why you should not provide an abstract base class for the request object (and possible others) so that developers (like me) have the option of mocking it. I think that this is one of the great qualities of the MVC API (and something that has been neglected in far too many .net APIs) and I do hope you will include that in the final release.