How to Intercept Requests in Playwright

If you’re using Playwright for end-to-end testing, you should check out Playwright Check Suites and start testing in production.

When we browse the web, a series of HTTP requests and responses are exchanged between our browser and the pages we are visiting. There are scenarios in which it is useful to monitor or manipulate this traffic.

Request interception

Request interception enables us to observe which requests and responses are being exchanged as part of our script’s execution. For example, this is how we could print them out when we load our test website:

request-interception-read.spec.ts

// Example code for request interception
import { test, expect } from '@playwright/test';

test('intercept requests', async ({ page }) => {
  // Listen for all requests
  page.on('request', request => {
    console.log('Request:', request.url());
  });

  // Listen for all responses
  page.on('response', response => {
    console.log('Response:', response.url(), response.status());
  });

  await page.goto('https://danube-web.shop/');
});

We might want to intervene and filter the outgoing requests. For example, when scraping web pages, we might want to block unnecessary elements from loading in order to speed up the procedure and lower bandwidth usage.

request-interception-block.spec.ts

// Example code for blocking requests
import { test, expect } from '@playwright/test';

test('block image requests', async ({ page }) => {
  // Block image requests
  await page.route('**/*', route => {
    if (route.request().resourceType() === 'image') {
      route.abort();
    } else {
      route.continue();
    }
  });

  await page.goto('https://danube-web.shop/');
});

As a result, you will see the website logo not being loaded.

Similarly, switching the resourceType to stylesheet would result in the target website loading without any CSS styling.

Response interception

Isolating one or more software components from their dependencies makes them easier to test. We can do so by substituting interactions with such dependencies with simulated, simplified ones. This is also known as stubbing.

Playwright makes it easy for us, as for every request we can intercept we also can stub a response.

Every time we load it, our test website is sending a request to its backend to fetch a list of best selling books. For our example, we are going to intercept this response and modify it to return a single book we define on the fly.

response-interception.spec.ts

// Example code for response interception
import { test, expect } from '@playwright/test';

test('intercept and modify response', async ({ page }) => {
  // Intercept API calls and return custom data
  await page.route('**/api/best-sellers', route => {
    const customResponse = {
      books: [
        {
          title: 'Custom Book Title',
          author: 'Custom Author',
          genre: 'Custom Genre',
          price: '$19.99',
          rating: '4.5 stars'
        }
      ]
    };

    route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify(customResponse)
    });
  });

  await page.goto('https://danube-web.shop/');
});

Here is what the homepage will look like with our stubbed response:

Run the above examples as follows:

npx playwright test request-interception.ts

Takeaways

1. Playwright gives us control over outgoing HTTP requests.
2. Playwright can easily stub HTTP responses.

Avoid Network Interception in Synthetic Monitoring

Network interception is valuable if your primary goal is to test a frontend application in isolation. However, if you want to test your application end-to-end or use Playwright for synthetic production monitoring with Checkly you should avoid network interception as much as possible.

The goal of end-to-end testing and synthetic monitoring is to test the entire stack ranging from the backend systems to the last third-party JavaScript snippet being loaded in the frontend.

• You won’t learn about your image CDN’s downtime if your tests block image requests to save bandwidth.
• You will never learn about your flaky checkout API flow if you mock all the /order requests.
• You won’t be notified when a tracking script breaks your page layout if you block third-parties in your tests.

Investing in fully end-to-end testing and monitoring can be challenging but it’ll provide you the safety net you’re aiming for.

Further reading

1. Official documentation on this topic from Playwright.
2. Mocks Aren’t Stubs by Martin Fowler.

Bugs don’t stop at CI/CD. Why would Playwright?

Sign up and start using Playwright for end-to-end monitoring with Checkly.