I ❤️ .NET

Table of Contents

1. What we gonna do?
2. Why we gonna do?
3. How we gonna do?
4. Summary

What we gonna do?

In this article, let's learn about how to Unit Test HTTPClient in .NET.

Note: If you have not done so already, I recommend you read the article on Extending HTTPClient with Custom Http Message Handlers in dotnet.

There are multiple ways to Unit Test HTTP Client in dotnet. Most of the examples you will find on the internet will be using Moq or NSubstitute. But I prefer to write Custom Http Message Handlers to Unit Test HTTP Client in dotnet.

Why we gonna do?

Integrating with a web API is a common task required by many applications. Http Client is a class that simplifies the consumption of web APIs. It provides a base class for sending HTTP requests and receiving HTTP responses from a resource identified by a URI. The HttpClient class is typically used to send and receive requests from a web service by using the HTTP protocol.

Most of the time I see developers including me say we can test HTTP Client or calls in Integration Test but Unit testing allows developers to verify the behavior and logic of individual units of code in isolation quickly. By writing tests, you can ensure that your code functions correctly and remains reliable even after making changes or adding new features. Unit tests are faster and help catch bugs early in the development process and provide confidence in the correctness of the code.

Note: If you have not done so already, I recommend you read the article on Implementing TDD in C# .Net.

How we gonna do?

You're working on a part of your application that relies on HttpClient to make API calls. Testing this can become cumbersome, as you don't want to actually call the API. Because it's not an integration test. Moreover, constantly calling a service that's cloud hosted can cost you quite a bit of money. You just want to test one specific piece of functionality that happens to rely on data being returned from an HTTP call.

Take error handling, for example. You want to ensure that when the API responds with a dreaded 401 Unauthorized status code that your application handles it gracefully. You don't want to actually call the API, though. You just want to ensure that your application handles the response correctly. This is where Custom Http Message Handlers come in handy. Well, we can write a custom handler to stop communication with the API and return the response required for our test. For our use case, we don't want to communicate with the API, but we do want to get back a 401 Unauthorized response.

The following code shown a simple implementation of a custom message handler that returns a 401 Unauthorized response. Notice that we are using HttpMessageHandler instead of DelegatingHandler. This is because we don't want to pass the request to the next handler in the pipeline. We want to return the response we want. So, we are using HttpMessageHandler to short circuit it.

Now, we can use this custom message handler to unit test our http client. The following code shows a simple implementation of a unit test for http client. All we need to do is to pass our custom message handler to the http client and make the http call. The http call will be intercepted by our custom message handler and will return the response we want which is 200 Success Status Code in our case. This will help you to assert your code against the response you want.

Here is another similar example for 401 UnAuthorised Status Code.

The only drawback of this approach is that you need to write a custom message handler for each status code you want to test. I feel like we will also need to maintain these custom message handlers. But this is the best approach I found to unit test http client in dotnet when there is no option available to mock the http client.

Summary