Playwright stories: Network interception and why you may want to use it
Greetings to all the automation enthusiasts, including esteemed test automation engineers!
Today, we will explore a powerful test automation approach that allows us to intercept and modify network requests initiated by a web application during testing. In this article, I will demonstrate the seamless interception and mocking capabilities provided by Playwright that make the process incredibly easy.
You can find some of the requests in Browser Developer Tools → On Network tab. If you see some of the requests, then we can work.
But first, let’s start with a question: why would you want to do interception and mocking?
Why you may want to use it?
Test edge cases or alternative flows
First, you can think about edge cases you might want to test on the UI. For example, you may want to see the behavior of some section when you don’t have any data at all or maybe you have too much data. As an example, you have pagination component that appears only some amount of data. Or label should be displayed when there is no data. Or HTML markup may change depending on the amount of data provided. These are just some examples.
But in such cases, you usually have to prepare test data or environment to some state. And sometimes, I tell you, it can be a real challenge and pain. On the other hand, you can just return data that you want to display or not display.
Boundary value and negative scenario testing
This is mostly a continuation of the previous point. You may want to see how the system displays data from the limits. Like this: )
Or you may want to return some 40x or 50x errors. Or you want to return some negative price value. Maybe your API is designed so well (maybe…) that you cannot even emulate such a case with real API calls.
Security testing
You can use request interception to test security vulnerabilities, such as CSRF (Cross-Site Request Forgery) or XSS (Cross-Site Scripting) attacks.
Testing Authentication and Authorization
You can use request interception to handle authentication and authorization mechanisms, allowing you to test different user roles and permissions.
Testing Offline Functionality
By intercepting network requests, you can simulate an offline environment and verify how the application behaves when it can’t access the internet.
A/B Testing
Request interception can be used to simulate different A/B testing scenarios and validate the correct behavior of each variation.
Testing Loading States
In web applications, requests are often made to load data. Intercepting these requests allows you to control the loading states and test how the application behaves when data is being fetched
Testing Third-Party Integrations
Intercepting requests to third-party APIs allows you to verify proper integration and handle edge cases.
I don’t think this is a complete list of use cases. I think you can find more. As usual, you may have to deal with some limitations.
What limitations you may face with?
Unfortunately, not every website displays REST API responses in the Network tab for several reasons:
Encryption and Privacy
Many websites use HTTPS (SSL/TLS) encryption to secure the communication between the client (browser) and the server. In such cases, the network requests and responses are encrypted, and the data exchanged between the client and server cannot be easily viewed in plain text. This encryption ensures the privacy and security of sensitive information transmitted over the network.
Cross-Origin Resource Sharing (CORS)
Modern web browsers enforce a security feature called Cross-Origin Resource Sharing (CORS). CORS restricts web pages from making requests to a domain that is different from the domain of the web page making the request. This security measure prevents potential attacks such as cross-site request forgery (CSRF). If the REST API is hosted on a different domain than the website, the browser might block the API request, and it won’t be visible in the Network tab.
APIs on Different Domains
Some websites load resources from multiple domains. If the REST API is hosted on a different domain (subdomain or entirely different domain), it may not be visible in the Network tab due to CORS restrictions.
Server-Side Rendering
In server-side rendering (SSR) or static site generation (SSG) frameworks, the API calls may be executed on the server side during page rendering. These requests and responses might not be visible in the Network tab of the client-side browser since they were handled on the server.
Data Fetching Techniques
Websites use various data-fetching techniques, such as AJAX, Fetch API, Axios, GraphQL, etc. Depending on how the data is fetched, some methods may not be captured in the Network tab.
Response Format
The API responses might be in a format that the browser doesn’t automatically parse or display in the Network tab. For example, if the response is in JSON format, it might not be directly visible in the Network tab, but you can see it in the response tab or through JavaScript console logging.
Despite not being visible in the Network tab, API responses can still be captured and analyzed using other methods, such as browser developer tools, proxy servers, network monitoring tools, or debugging tools provided by API clients like Postman or Insomnia. It’s essential to respect the security measures and privacy concerns of websites and APIs, and not all information is intended to be exposed through browser developer tools
Finally it’s a time to jump into the interception process
Interception with Playwright
We will consider some, but certainly not all, of these cases. And let’s start with just logging the response. In this case, we can see what test data is being returned and how we can manage it in the future.
Intercept, log and continue
With Playwright, all you need to do is access the “context” and use the “route” method. All the other magic will happen inside, depending on what you want to implement.
In my example above, I’m fetching the response and getting JSON.
Note: “fetch” method — Performs the request and fetches result without fulfilling it, so that the response could be modified and then fulfilled.
Then I log JSON file and continue request as if nothing happened. It means I’m not changing any logic, except logging the response data.
The result will be a very long response with JSON data. UI logic should work as usual
Good? Let’s try to do something bad and cancel the request — ho ho ho
Intercept and abort
This time it will be even easier. We just call the “abort” method inside the “route” method and that’s it. Simple as that.
In the results, request should not be returned. On UI there might be a different behavior. As an example, of WebSite where I tested it, all sections with Desserts, Pizzas and Drinks were hide. Including section names.
- Example of normal website status:
- Website status after response
Important note: “KYIV”, but not “KIEV”.
The spelling “Kyiv” is a more accurate and modern transliteration of the Ukrainian name “Київ,” which is the official name of the capital city of Ukraine. The use of “Kyiv” is based on the Ukrainian government’s request and international standards for transliteration
Intercept and change data
We have done some simple cases. But let’s try to modify our response a bit. As an example, this time I will only return 1 section with 1 pizza.
How to do it? Still simple, but need to work a little with JSON object. Good sign, you already have a complete object and now you can modify it.
In my case, it was an array of objects, so I left only one object. It is still very large in a full response.
Now what we need to do is to use “fulfill” method and return data we want.
As you can see, we have only changed the body’s response. But it’s not limited to that. We can change some other parts of the response as well. For example StatusCode.
Let’s see how the system behaves
As you can see, only one section and one product is displayed. Let’s assume that this is the expected behavior. At least it looks like it. You can play around with it if you like, but I think you get the general idea.
Playwright can intercept more than just API requests. For example, we may want to block some of the images or CSS. Let’s look at a small example in the next subsection.
Intercept of non API calls
On the website I use for the experiments, we can see a beautiful main image.
Let’s just block this image from uploading. But first, let’s find it on the NETWORK tab of the browser. If you switch to ALL requests, you might find more than just API calls.
Here we find the request for the main image.
We have URL and we can perform the same “abort” action with a different request. We just change our intercept URL.
Let’s run our test. Result is image slide is not available.
One more thing, I forgot to tell is you don’t need to specify full request interception path. You may use only stable part of the request and rest of the part can be separated by stars.
Conclusion
I think it looks really great to have such a tool. It can help you to avoid some big and difficult data setup. You can perform request interception with other tools too. But Playwright’s built-in feature makes it extremely powerful.
Thanks a lot for reading this article.
More information can be found in the official Playwright documentation: https://playwright.dev/docs/network
Example project, as usually available on GitHub: https://github.com/dneprokos/playwright-test-demo/blob/main/_project-test-automation-site-tests/tests/request-interception.tests.ts
Good luck and stay curious……
