In this post, we take a look at the benefits and possibilities while intercepting HTTP requests in your Playwright tests.
Before we dive into the Playwright examples, let's first take a look at the Angular component. The component below makes a single HTTP request to fetch a collection of posts and renders the result in a list. If the request should fail, the component displays an error message instead.
The default behavior of a test written with Playwright is to make real HTTP requests. This is great for testing the end-to-end behavior of the application, and it gives you the biggest confidence that the application is working correctly.
To write a simple test case for the application, we simply navigate to the home page and expect that a post is rendered.
This is exactly what the following test case does.
Notice that we don't need to put a wait statement in the test. This is because Playwright automatically waits until the assert passes. When it takes too long, this throws an error and the test fails.
While letting the requests hit the real server is great for testing the actual behavior of the application, it is not ideal for testing specific edge cases. Here, you want to have full control over the request and the response.
Yes, you could also accomplish this by putting the API in the desired state, but this is often more time-consuming than intercepting the request with Playwright.
An intercepted HTTP request allows you to return a mocked response while preventing the request is sent to the server.
In Playwright, this is done by using the
page.route method. The first argument is the route that needs to be intercepted, and the second argument is a callback method that returns a response.
In the example below, the posts endpoint is intercepted and with the usage of
route.fulfill it creates a mocked response.
To represent a real response, a posts array (which contains a single post) is assigned to the response body.
Note that the
** wildcard syntax is used to ignore the delay query parameter, which was added to the end of the endpoint.
Intercepting HTTP requests is powerful because it allows you to fully build the response of a request with the needed customizations for your needs.
In the previous example, we've seen how to create a mocked response in which we set the body. Instead of returning a successful response, it's also possible to return an error response. Doing this is a quick and useful way to test the error handling of the application.
To create a response that resulted in an error, we make use of the
The result of the test below is that the application displays an error message because there went something wrong during the request.
Last, but not least, we can also make the original request and modify the response. I like to use this method because it's the best of both worlds. We still test the interaction between the application and the server, but we still have to possibility to create edge cases without a lot of overhead.
page.route method of Playwright allows you to intercept HTTP requests and return a mocked response.
Because you are fully in control of the response, this enables you to create edge cases to cover all the possible scenarios in a quick way without introducing a lot of overhead.
The Playwright API is flexible enough to be used in different ways. You can just create a mocked response, return an error, or you can make the original request and modify the response.
As an extra tip, you could do more than just mocking HTTP API requests. In certain cases, aborting image requests may result in a significant speed boost, this is exactly what the next snippet accomplishes.
I appreciate it if you would support me if have you enjoyed this post and found it useful, thank you in advance.