3.5 KiB
HTTP client - Test requests
As for any external dependency, you must mock the HTTP backend so your tests can simulate interaction with a remote server.
The @angular/common/http/testing library makes it straightforward to set up such mocking.
HTTP testing library
Angular's HTTP testing library is designed for a pattern of testing in which the app executes code and makes requests first. The test then expects that certain requests have or have not been made, performs assertions against those requests, and finally provides responses by "flushing" each expected request.
At the end, tests can verify that the app made no unexpected requests.
You can run these sample tests in a live coding environment.
The tests described in this guide are in src/testing/http-client.spec.ts.
There are also tests of an application data service that call HttpClient in src/app/heroes/heroes.service.spec.ts.
Setup for testing
To begin testing calls to HttpClient, import the HttpClientTestingModule and the mocking controller, HttpTestingController, along with the other symbols your tests require.
Then add the HttpClientTestingModule to the TestBed and continue with the setup of the service-under-test.
Now requests made in the course of your tests hit the testing backend instead of the normal backend.
This setup also calls TestBed.inject() to inject the HttpClient service and the mocking controller so they can be referenced during the tests.
Expect and answer requests
Now you can write a test that expects a GET Request to occur and provides a mock response.
The last step, verifying that no requests remain outstanding, is common enough for you to move it into an afterEach() step:
Custom request expectations
If matching by URL isn't sufficient, it's possible to implement your own matching function. For example, you could look for an outgoing request that has an authorization header:
As with the previous expectOne(), the test fails if 0 or 2+ requests satisfy this predicate.
Handle more than one request
If you need to respond to duplicate requests in your test, use the match() API instead of expectOne().
It takes the same arguments but returns an array of matching requests.
Once returned, these requests are removed from future matching and you are responsible for flushing and verifying them.
Test for errors
You should test the app's defenses against HTTP requests that fail.
Call request.flush() with an error message, as seen in the following example.
Alternatively, call request.error() with a ProgressEvent.
@reviewed 2022-11-14