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 use Moq and I can stub out the HttpClient. I think this the same for Rhino Mock (I haven’t tried by myself). 
If you just want to stub the HttpClient the below code should work: 

```cs
var stubHttpClient = new Mock<HttpClient>();
ValuesController controller = new ValuesController(stubHttpClient.Object);

```

Please correct me if I’m wrong. I guess you are referring to here is that stubbing out members within HttpClient.

Most popular isolation/mock object frameworks won’t allow you to stub/setup on non- virtual members
For example the below code throws an exception

```cs
stubHttpClient.Setup(x => x.BaseAddress).Returns(new Uri("some_uri");

```

You also mentioned that you would like to avoid creating a wrapper because you would wrap lot of HttpClient members. Not clear why you need to wrap lots of methods but you can easily wrap only the methods you need. 

For example :

```cs
public interface IHttpClientWrapper  {   Uri BaseAddress { get;  }     }

public class HttpClientWrapper : IHttpClientWrapper
{
   readonly HttpClient client;

   public HttpClientWrapper()   {
       client = new HttpClient();
   }

   public Uri BaseAddress   {
       get
       {
           return client.BaseAddress;
       }
   }
}

```

The other options that I think might benefit for you (plenty of examples out there so I won’t write the code)
Microsoft Moles Framework
<http://research.microsoft.com/en-us/projects/moles/>
Microsoft Fakes: (if you are using VS2012 Ultimate)
<http://msdn.microsoft.com/en-us/library/hh549175.aspx>