Using Network Interception in Playwright for Mocking API Responses

As modern web applications rely heavily on API communication, testing these API interactions becomes a critical part of ensuring application reliability. When running end-to-end tests, we sometimes want to control or mock API responses to simulate different scenarios. This is where network interception comes in. Playwright, a robust browser automation framework, offers a simple yet powerful API to intercept and mock network requests and responses.

In this article, we’ll explore how to use Playwright’s network interception capabilities to mock API responses, control network conditions, and create more comprehensive tests for your web applications.

Why Mock API Responses?

Mocking API responses in Playwright is useful for several reasons:

• Test Edge Cases: Mock responses allow you to simulate different server conditions like 404 errors, slow responses, or custom error messages without relying on the actual backend.
• Speed Up Tests: You can avoid delays caused by network requests during testing by mocking the API response locally, which speeds up the execution of tests.
• Isolated Testing: With mocked responses, you can test front-end functionality without depending on the availability or stability of the backend.
• Consistent Test Results: Mocking responses helps create predictable and repeatable test conditions, which is key for writing reliable automated tests.

How Network Interception Works in Playwright

Network interception allows Playwright to listen for network requests made by the browser, modify them, and mock the responses before they reach the browser. This is achieved by setting up an event listener to capture network traffic and using Playwright’s API to control how the requests and responses are handled.

Here’s a basic overview of how network interception is implemented in Playwright:

Step 1: Setting Up Playwright

First, ensure that Playwright is installed in your project by running the following command:

npm install playwright

Once Playwright is installed, set up a project directory and initialize a new project:

mkdir api-mocking-playwright
cd api-mocking-playwright
npm init -y

Step 2: Intercepting Network Requests

In your Playwright script, you can intercept network requests by setting up a route that listens to specific URL patterns. You can then decide whether to allow the request to proceed as normal, mock the response, or block it entirely.

const { chromium } = require('playwright');

(async () => {
    const browser = await chromium.launch({ headless: false });
    const page = await browser.newPage();

    // Intercept API requests
    await page.route('**/api/v1/*', (route) => {
        const mockedResponse = {
            status: 200,
            contentType: 'application/json',
            body: JSON.stringify({ message: 'Mocked API response' })
        };
        route.fulfill(mockedResponse);
    });

    // Navigate to the application
    await page.goto('https://example.com');

    // Interact with the page as usual
    await page.click('button#fetch-data');

    await browser.close();
})();

In this example:

• The page.route method intercepts all requests matching the URL pattern **/api/v1/*.
• We use the route.fulfill() method to mock a successful response with status 200 and a custom JSON payload.

Mocking Different Types of API Responses

To fully test your web application, it’s important to simulate various server responses and scenarios, such as success, failure, and slow responses.

1. Simulating Error Responses

Sometimes, you want to test how your application handles API errors like 404 (Not Found) or 500 (Internal Server Error). You can mock these responses using the route.fulfill() method:

await page.route('**/api/v1/data', (route) => {
    const errorResponse = {
        status: 500,
        contentType: 'application/json',
        body: JSON.stringify({ error: 'Internal Server Error' })
    };
    route.fulfill(errorResponse);
});

This will simulate a 500 error response, which allows you to verify how your application handles server errors.

2. Simulating Slow Network Responses

If you want to test how your application handles slow network conditions, you can delay the response by using the setTimeout function within the request interception handler:

await page.route('**/api/v1/data', (route) => {
    setTimeout(() => {
        const slowResponse = {
            status: 200,
            contentType: 'application/json',
            body: JSON.stringify({ message: 'Delayed response' })
        };
        route.fulfill(slowResponse);
    }, 5000); // Delay the response by 5 seconds
});

This simulates a slow API response and allows you to test how your application behaves under poor network conditions.

3. Mocking Authentication APIs

If your application requires user authentication via APIs, you can mock authentication requests to simulate both successful and failed login attempts. Here’s an example:

await page.route('**/api/v1/auth/login', (route) => {
    const authResponse = {
        status: 200,
        contentType: 'application/json',
        body: JSON.stringify({ token: 'mocked-jwt-token' })
    };
    route.fulfill(authResponse);
});

In this case, we’re mocking a successful login by returning a JWT token in the API response.

Best Practices for API Mocking with Playwright

• Isolate API Tests: Create separate test cases or suites for API mocking to ensure that your front-end functionality is tested independently of the actual backend.
• Test Error Handling: Always include test cases for edge cases, such as 404, 500, and timeout errors, to verify how your application handles failures.
• Mock with Realistic Data: When mocking API responses, use realistic data to simulate how your application will behave in production.
• Simulate Latency: Test your application’s performance under different network conditions by simulating slow responses and checking how loading states or spinners behave.
• Test Consistently: Use consistent mock data across test runs to ensure that your tests are predictable and reproducible.

Advanced Techniques for Network Interception

In addition to mocking API responses, Playwright’s network interception capabilities allow for more advanced testing scenarios:

1. Modifying Request Headers

You can modify outgoing request headers to simulate different user agents, API tokens, or content types. This is useful for testing how your application behaves under different conditions:

await page.route('**/api/v1/*', (route) => {
    const modifiedHeaders = {
        ...route.request().headers(),
        'Authorization': 'Bearer mocked-jwt-token'
    };
    route.continue({ headers: modifiedHeaders });
});

This allows you to modify the headers of network requests before they are sent to the server.

2. Blocking Requests

You can also block specific requests to test how your application behaves when certain resources (like images or scripts) are not available:

await page.route('**/*.jpg', (route) => {
    route.abort(); // Block all JPG image requests
});

This is useful for testing fallbacks and error handling when external resources fail to load.

Conclusion

Network interception in Playwright provides a powerful tool for testing your web application’s behavior in various scenarios. By mocking API responses, simulating errors, and controlling network conditions, you can create more robust and reliable tests.

Whether you're testing simple data fetching or complex authentication flows, mastering network interception will help you ensure that your web application performs well in all conditions. By following the techniques and best practices outlined in this article, you'll be able to leverage Playwright to its full potential for API testing and automation.