Using this, you can easily modify the behaviour of the HttpClient during your tests. This class is easy to mock too, as it only has a single method to implement: protected abstract Task SendAsync(HttpRequestMessage request, CancellationToken cancellationToken). The HttpClient has a constructor overload that takes an instance of the abstract class HttpMessageHandler, and this is the class does the actual heavy lifting within the HttpClient. The solution: Replace the HttpMessageHandler within HttpClient Instead, you replace the inner workings of the HttpClient for your tests. This means, you really don't mock HttpClient. That is also discussed in a lengthy thread on the CoreFx repo itself. It turned out that the approach to mock HttpClient isn't the way to go. So I did some reading, looked at things and thought about the whole situation from some different point of views.
And when something constantly gets in my way like this did, I like to think about whether it might be my way that's problematic. It is more likely that a HttpClientFactory controls it, and you don't see a way to extend it so that it instanciates your wrapper type instead.īack to square one it is. And then you might think about how the HttpClient gets injected in your class in the first place, as you have to swap out this injection against your wrapper type.Īnd then it strikes you again: You usually don't control the HttpClient lifetime directly. While this could technically work, your will notice that HttpClient has a lot of methods you'd need to bridge over to the real implementation. The next idea you could come up with is to wrap the HttpClient in another class (aka Decorator pattern), and mock this out. Even worse, the methods that you call on the HttpClient are not virtual, so you don't have a chance to override them.įirst (not so good) idea: Wrap the HttpClient.Secondly, it doesn't even have an abstract base class you could use.First, the HttpClient does not have an interface which you could use for mocking.While trying to replace your HttpClient with a mock of it, you will have noticed the following facts. Why did you get stuck in the first place? Mock HttpClient - and run into problems
#Http client c how to#
The long answer, and how to actually do it, is as follows. This is easier as you thought, but just not that intuitive in the first place. You are going to mock out a dependency of the HttpClient instead to achieve what you want. I give you the short answer right away: You don't. So, how would you mock HttpClient for your unit tests? After googling 'How to mock HttpClient' you landed on this post. You decide to mock out your dependency on HttpClient, and soon thereafter you got stuck. Since you want a unit test and not an integration test, it should not call a real http endpoint. "setup": "We really shouldn't care what people at the Oscars say,"Įxtending HTTP Client SDKs.You have a class that depends on HttpClient (or IHttpClientFactory for that matter), and want to unit test that. "punchline": "They are all paid actors anyway," HttpClient.AddDadJokesHeaders(host, configuration) Īpp.MapGet("/", async (IDadJokesApiClient client) => await client.GetRandomJokeAsync()) Services.AddDadJokesApiClient(httpClient => Var configuration = builder.Configuration NET 6 MinimalAPI example: var builder = WebApplication.CreateBuilder(args) The most common scenario is web applications. Task GetRandomJokeAsync(CancellationToken cancellationToken) String id, CancellationToken cancellationToken) String term, CancellationToken cancellationToken) When developing a Client SDK to be used with an API, it is a good idea to start from the interface contract (between the API and the SDK):
0 kommentar(er)
