How do you automate network failure scenarios in Playwright?

Question

QA Hacks Team · Accepted Answer

Automating network failure scenarios in Playwright primarily leverages its robust `page.route()` API for network interception. This allows us to precisely control network requests and responses, simulating various error conditions.

Here's a structured approach:

1.  **Intercept Requests with `page.route()`:**
    The core mechanism is to register a route handler that intercepts specific URL patterns. This handler can then decide how to respond.

```typescript
    await page.route('**/api/*', async route => {
      // Logic to simulate failure
    });
    ```

2.  **Simulate Hard Network Failures (`route.abort()`):**
    To simulate a complete network outage, connection refused, or DNS lookup failure, `route.abort()` is the most direct method. This prevents the request from ever reaching the server.

```typescript
    // Abort all API calls to simulate network down
    await page.route('**/api/*', route => route.abort('failed')); // 'failed' is a common error reason
    // Or specifically for a resource
    await page.route('**/images/*', route => route.abort());
    ```

3.  **Simulate Specific HTTP Error Responses (`route.fulfill()`):**
    For more granular control, such as simulating a 500 Internal Server Error, 404 Not Found, or 401 Unauthorized, we can use `route.fulfill()` to provide a custom response without the request ever hitting the actual server. This is essential for testing error message display and fallback UI.

```typescript
    // Simulate a 500 Internal Server Error for a specific endpoint
    await page.route('**/api/data', route => {
      route.fulfill({
        status: 500,
        contentType: 'application/json',
        body: JSON.stringify({ message: 'Simulated server error' }),
      });
    });

// Simulate a 404 Not Found for a static asset
    await page.route('**/broken-image.png', route => {
      route.fulfill({ status: 404 });
    });
    ```

4.  **Targeting Specific Requests:**
    Playwright supports glob patterns and regular expressions for `page.route()`, enabling precise targeting of API endpoints, static assets, or even external third-party calls. This ensures minimal disruption to other network traffic not relevant to the failure scenario.

5.  **Test Isolation and Cleanup:**
    It's critical to ensure network routes are isolated per test. Using `test.beforeEach` and `test.afterEach` hooks to set up and tear down routes is a best practice. `page.unroute()` can be used for explicit cleanup, or simply allowing the `page` context to be destroyed if running in isolated tests.

6.  **Assertion and UI Verification:**
    After triggering a network failure, the test must assert that the application's UI reacts as expected. This includes:
    *   Displaying appropriate error messages (e.g., "Failed to load data").
    *   Showing fallback UI components or empty states.
    *   Disabling interactive elements to prevent further erroneous actions.
    *   Validating that the application doesn't crash or enter an unrecoverable state.

```typescript
    // After route.abort() or route.fulfill(500)
    await expect(page.locator('.error-message')).toHaveText('Failed to fetch data. Please try again.');
    ```

By combining these techniques, Playwright provides a powerful and flexible way to rigorously test application resilience against a wide range of network failure scenarios, significantly enhancing application quality.

### Speaking Blueprint (3-Minute Verbal Response):

[The Hook]
In today's distributed systems landscape, where our front-end applications depend heavily on numerous backend services and external APIs, ensuring a robust user experience even under adverse network conditions is paramount. Our modern automation frameworks, specifically Playwright, provide incredibly powerful capabilities to proactively address this challenge, moving beyond just happy path validation.

[The Core Execution]
At its core, Playwright's `page.route` API is our central mechanism for simulating network failures. We use this API to intercept any outgoing network request from the browser. For simulating a complete network outage, such as a DNS lookup failure or connection refused, we'd leverage `route.abort()`. We can target specific patterns, for example, `**/api/*`, and immediately abort those requests, mimicking a truly disconnected state. This allows us to verify how the application behaves when its primary data sources are unreachable, ensuring it displays appropriate error messages or fallback content rather than hanging indefinitely.

For more granular control, like simulating specific HTTP errors—think a 500 Internal Server Error from an API, a 404 for a missing resource, or a 401 for an unauthorized request—we employ `route.fulfill()`. With `route.fulfill()`, we can craft custom responses, setting the HTTP status code, headers, and even a response body. This lets us precisely test how our UI handles different server-side error messages, ensuring our error handli

How do you automate network failure scenarios in Playwright?

📋 Interview Context

Overview

Interview Question:

Expert Answer:

Speaking Blueprint (3-Minute Verbal Response):

Continue Learning: Up Next

How do you analyze defect leakage across releases?

How do you assess release readiness using quality metrics?

How do you audit production incidents using logs and metrics?