You can't unit test it like that. It's like you mentioned: HttpClient is a dependency, and as such, it should be injected.
Personally, I would create my own IHttpClient interface, implemented by HttpClientWrapper, which wraps around the System.Net.HttpClient. IHttpClient would then be passed as a dependency to your object's contructor.
As follows, HttpClientWrapper can't be unit tested. I would, however, write a couple of integration tests to make sure the wrapper is well written.
Edit:
IHttpClient doesn't have to be a "valid" interface for HttpClient. It only has to be an interface that suits your needs. It can have as many or as few methods as you want.
Picture this: HttpClient allows you to do many things. But in your project, you're only calling the GetAsync(uri).Result method, nothing else.
Given this scenario, you would write the following interface and implementation:
interface IHttpClient { HttpResponseMessage Get(string uri); } class HttpClientWrapper : IHttpClient { private readonly HttpClient _client; public HttpClientWrapper(HttpClient client) { _client = client; } public HttpResponseMessage Get(string uri) { return _client.GetAsync(new Uri(uri)).Result; } } So, as I stated previously, the interface only has to suit your needs. You don't have to wrap around the WHOLE HttpClient class.
Obviously, you would then moq your object like this:
var clientMock = new Mock<IHttpClient>(); //setup mock var myobj = new MyClass(clientMock.object); And to create an actual object:
var client = new HttpClientWrapper(new HttpClient()); var myobj = new MyClass(client ); Edit2
OH! And don't forget that IHttpClient should also extend the IDisposable interface, very important!