It won't be much of a Web Application if it doesn't make HTTP requests, does it? However, it's easy to forget that these need to be tested as well!
In this article, I'll cover how to unit test HTTP requests in your Angular Application so you can have the confidence that they'll always work as expected.
Code for the article can be found here.
Let's say that our HTTP calls live in a service that handles to-do items. We can do our basic CRUD operations: getting our to-do items or a single one, creating new items, updating or deleting items.
I'll be using JSONPlaceHolder for this since it's the quickest way to get started. The most barebones CRUD service should look like this:
HttpClientTestingModule, the auto-generated spec file should look like this:
At this point your only test ("it should be created") should be passing.
Remember that during testing, we're not actually making any requests. We're only concerned with if the request was sent and if a response is handled properly when it returns. Anything that happens in between that is out of the scope of unit testing.
Therefore, let's say that we're unit testing a GET request, we only care that the request is sent and, if the request is successful, some data comes back.
Keep in mind that Angular HttpClient uses Observables rather than promises so we have to adjust our tests accordingly!
Angular provides an entire module to help us test HTTP Requests called the
HttpClientTestingModule that allows us to:
- Mock a request
- Create a fake request with any status code
- Pass along a response with fake data
- Cancel a request
- And much much more!
This means we can test our requests from every angle possible and have our application handle as much cases as possible. I'll cover these in future articles. Let's get set up!
We need to establish a Mock network that allows us to control when requests are sent, what data is returned and whether or not the request was successful. This comes in the form of
HttpTestingController as seen below:
Notice that in the
afterEach block, we called
httpMock.verify(). This ensures that there are no pending requests in our mock network before moving on to other tests.
Now we can really start testing our code!
We want to test
getSingleTodo. Based on the function name, we can expect that the HTTP response will contain a todo object. Let's represent our expectations as tests.
In the above code, we:
- ran our
getSingleTodofunction and expected the result to be defined
- used the controller to expect a request to have the URL
- expected the request to be a GET request
- used the controller to manually send the request with the fake todo data.
Under normal circumstances, the
getSingleTodo function would have made an actual request but our
HttpTestingController intercepted the request and returned the fake data using
We can now use this information to test POST requests. These contain a request body and can return data along with the status code.
This test ensures a POST request is sent to the correct URL and the created data is returned.
In this article, we learned:
- the theory behind testing HTTP requests by using a mock network
- setting up the mock network using
- running fake requests and testing their URLs, methods and return values
The next article will show how to control fake requests so we can test our application in the event of unauthorized requests, server crashes and basic error handling.
Hope you enjoyed reading! 😄