Question: I am using the new Web API bits in a project, and I have found that I cannot use the normal `HttpMessageRequest`, as I need to add client certificates to the request. As a result, I am using the `HttpClient` (so I can use `WebRequestHandler`). This all works well, except that it isn't stub/mock friendly, at least for Rhino Mocks. 

I would normally create a wrapper service around `HttpClient` that I would use instead, but I would like to avoid this if possible, as there are a lot of methods that I would need to wrap. I am hoping that I have missing something—any suggestions on how to stub `HttpClient`?

Answer: 
As an alternative to the excellent ideas already presented by @Raj, it may be possible to go a step lower and to mock/fake the `HttpMessageHandler` instead.

If you make any class that needs an `HttpClient` accept it as a dependency injection parameter in the constructor, then when unit testing you can pass in an `HttpClient` that has been injected with your own `HttpMessageHandler`. This simple class has only one abstract method that you need to implement, as follows:

```cs
public class FakeHttpMessageHandler : HttpMessageHandler
    {
    public HttpRequestMessage RequestMessage { get; private set; }

    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
        RequestMessage = request;
        return Task.FromResult(new HttpResponseMessage(HttpStatusCode.OK));
        }
    }

```

My trivial example just saves the `HttpRequestMessage` in a public property for later inspection and returns HTTP 200 (OK), but you could augment this by adding a constructor that sets the result you want returned.

You'd use this class like this:

```cs
public void foo()
    {
    //Arrange
    var fakeHandler = new FakeHttpMessageHandler();
    var client = new HttpClient(fakeHandler);
    var SUT = new ClassUnderTest(client);

    //Act
    SUT.DomSomething();

    //Assert
    fakeHandler.RequestMessage.Method.ShouldEqual(HttpMethod.Get); // etc...
    }

```

There are limitations to this approach, for example in a method that makes multiple requests or needs to create multiple `HttpClient`s, then the fake handler might start to become too complicated. However, it may be worth consideration for simple cases.
I released a library a few months ago called [MockHttp](http://www.nuget.org/packages/RichardSzalay.MockHttp/) which might be useful. It uses a custom `HttpMessageHandler` with a fluent (and extensible) API. You can inject the mocked handler (or HttpClient) into your service class and it will respond as it was configured.

Below shows basic usage. The `When` and `Respond` methods have a bunch of overloads, including running custom logic. The [documentation on the GitHub page](https://github.com/richardszalay/mockhttp) goes into a lot more detail.

```cs
var mockHttp = new MockHttpMessageHandler();

// Setup a respond for the user api (including a wildcard in the URL)
mockHttp.When("http://localhost/api/user/*")
        .Respond("application/json", "{'name' : 'Test McGee'}"); // Respond with JSON

// Inject the handler or client into your application code
var client = new HttpClient(mockHttp);

var response = async client.GetAsync("http://localhost/api/user/1234");
// or without async: var response = client.GetAsync(...).Result;

var json = await response.Content.ReadAsStringAsync();

// No network connection required
Console.Write(json); // {'name' : 'Test McGee'}

```