How do you validate API mocking behavior in Playwright?

Question

QA Hacks Team · Accepted Answer

Validating API mocking in Playwright involves a multi-layered approach, ensuring the mock is active, the application reacts correctly, and optionally, that specific network requests are indeed intercepted or passed through as intended.

**1. Setting Up the Mock:**
Playwright's `page.route()` API is central. We define interception patterns and provide mock responses.

```typescript
await page.route('**/api/users', async (route) => {
  const jsonResponse = [{ id: 1, name: 'Mock User' }];
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify(jsonResponse),
  });
});
```
For complex scenarios, dynamic mocks can be generated based on the incoming request:
```typescript
await page.route('**/api/items/*', async (route) => {
  const itemId = route.request().url().split('/').pop();
  await route.fulfill({
    status: 200,
    contentType: 'application/json',
    body: JSON.stringify({ id: itemId, description: `Mock item ${itemId}` }),
  });
});
```

**2. Validation Strategies:**

*   **UI-Level Assertions (Primary):**
    The most direct validation is asserting that the User Interface reflects the data or state provided by the mock. This confirms the application successfully consumed the mocked response.
    ```typescript
    await expect(page.getByText('Mock User')).toBeVisible();
    await expect(page.locator('.user-list')).toHaveCount(1);
    ```
    For error mocks, assert error messages or UI elements indicative of failure:
    ```typescript
    await page.route('**/api/users', r => r.fulfill({ status: 500 }));
    await page.goto('/users'); // Trigger the request
    await expect(page.getByText('Failed to load users')).toBeVisible();
    ```

*   **Network-Level Assertions (Secondary & Advanced):**
    While the UI validation is critical, sometimes you need to confirm *how* the mock was applied or if specific requests *were not* mocked and proceeded.

*   **Asserting a Request was Mocked/Intercepted:**
        We can capture and inspect network requests and responses *after* setting up mocks but before `route.fulfill()`. More commonly, we validate that the *application* made the expected request, even if it was intercepted.
        ```typescript
        const [request] = await Promise.all([
          page.waitForRequest('**/api/users'),
          page.goto('/users'), // Triggers the request
        ]);
        // No direct assertion on `request` being fulfilled by mock,
        // but we know the application made the request.
        // UI assertions confirm the result of the mock.
        ```

*   **Asserting Request/Response Payloads:**
        For dynamic mocks or verifying correct data submission, we can inspect outgoing request bodies or incoming response headers before they are fulfilled.
        ```typescript
        await page.route('**/api/data', async (route) => {
          const postData = route.request().postDataJSON();
          expect(postData).toEqual({ someKey: 'expectedValue' }); // Validate request payload
          await route.fulfill({ status: 200, body: JSON.stringify({ success: true }) });
        });
        // ... then trigger the request ...
        ```

*   **Verifying Non-Mocked Requests:**
        Ensuring other, non-mocked requests still proceed or behave as expected.
        ```typescript
        const [apiCall] = await Promise.all([
            page.waitForResponse('**/api/otherdata'), // Wait for an actual backend call
            page.click('button-triggering-other-data'),
        ]);
        expect(apiCall.status()).toBe(200);
        ```

**3. Best Practices:**
*   **Isolation:** Each test should set up its own mocks to prevent interference.
*   **Reusability:** Abstract common mocking patterns into helper functions or a dedicated mocking utility within the framework.
*   **Clarity:** Name your routes clearly to understand their purpose.
*   **Cleanup:** Mocks are typically scoped to a test or `beforeEach`/`afterEach` block and automatically cleaned up by Playwright. For manual cleanup, `route.abort()` or `route.continue()` are available.

By combining UI-level assertions with strategic network-level checks, we gain high confidence that our API mocks are behaving as intended and our frontend logic is robust across various backend conditions.

### Speaking Blueprint (3-Minute Verbal Response):
[The Hook]
In modern web development, especially with complex Single Page Applications, robust API mocking is absolutely non-negotiable for achieving fast, stable, and scalable end-to-end and component test suites. It's how we isolate frontend logic, prevent external dependencies from causing flakiness, and drastically speed up our feedback loop.

[The Core Execution]
When it comes to validating API mocking behavior in Playwright, our approach is multi-faceted, focusing on both the expected application state and, where necessary, the underlying network interaction. We primarily leverage Playwright’s powerful `page.route()` API.

How do you validate API mocking behavior 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 API dependencies before deployment?

How do you assess deployment risk using quality metrics?