How do you test WebSocket reconnection in Playwright?

Question

QA Hacks Team · Accepted Answer

Testing WebSocket reconnection in Playwright demands a multi-faceted approach, primarily focusing on simulating the disconnection event and then meticulously monitoring and asserting the client's recovery. The core challenge lies in triggering a server-side WebSocket closure and verifying the client-side re-establishment of the connection and data integrity.

1.  **Simulating Disconnection (Controlled Chaos):**
    The most reliable way to force a WebSocket disconnection from a test is to leverage a dedicated API endpoint on the backend in a test environment. This allows Playwright to make an HTTP request that explicitly terminates a specific user's WebSocket connection on the server. This provides precision unmatched by network throttling, which might only simulate latency rather than an outright close.
    ```typescript
    // Example: Playwright making an API call to force server-side disconnect
    await page.request.post('http://localhost:3001/api/force-disconnect', {
      data: { sessionId: 'currentPlaywrightTestSession' }
    });
    ```
    Alternatively, one could use Playwright's `page.emulateNetworkConditions` to simulate severe network drops, though this is less deterministic for *forcing* a server-side close.

2.  **Monitoring WebSocket Events (Client-side Observation):**
    Playwright's `page.on('websocket')` event listener is the cornerstone for client-side monitoring. We attach listeners to track the lifecycle of WebSocket connections.
    ```typescript
    let wsClosedCount = 0;
    let wsOpenCount = 0;
    const wsEvents = []; // To log received/sent frames for deeper inspection

page.on('websocket', ws => {
      wsOpenCount++;
      ws.on('close', () => {
        wsClosedCount++;
        wsEvents.push('closed');
      });
      ws.on('framereceived', frame => {
        wsEvents.push(`received: ${frame.payload.toString().substring(0, 50)}...`);
      });
      // Additional listeners for error, framesent if needed
    });
    ```
    A robust test framework would encapsulate this in a `WebSocketMonitor` utility class. This class could offer methods like `waitForWebSocketClose()` (which waits for `wsClosedCount` to increment) and `waitForNewWebSocketConnection()` (which waits for `wsOpenCount` to increment beyond the initial connection, indicating a successful reconnection attempt).

3.  **Verification and Assertions (Post-Reconnection Integrity):**
    After triggering the disconnect and awaiting the client-side reconnection, the critical step is to verify the application's state and data flow.
    *   **UI Status:** Assert that the UI reflects a "connected" status.
        ```typescript
        await expect(page.locator('#connection-status')).toHaveText('Connected', { timeout: 10000 });
        ```
    *   **Data Integrity:** Send a new message from the client (e.g., via a UI input) and verify its successful round-trip, or assert that new real-time updates from the server are correctly displayed. This confirms the WebSocket is fully functional.
        ```typescript
        await page.fill('#message-input', 'Test message post-reconnect');
        await page.click('#send-button');
        await expect(page.locator('#chat-log')).toContainText('Test message post-reconnect', { timeout: 15000 });
        ```
    Playwright's `expect` assertions are crucial here, especially with custom timeouts to account for the asynchronous nature and potential back-off strategies of reconnection logic.

4.  **Framework Best Practices:**
    *   **Isolation:** Ensure each test starts with a clean slate, typically by logging out/in or resetting the backend's WebSocket session state.
    *   **Page Object Model (POM):** Embed WebSocket monitoring logic within relevant Page Objects or a dedicated `RealtimeFeaturePage` to maintain modularity and readability.
    *   **Retry Logic:** Leverage Playwright's auto-retrying assertions (`expect().toHaveText()`, `expect().toBeVisible()`) extensively, as network events are inherently asynchronous. For custom waits, `page.waitForFunction` or `await Promise.race` combined with `page.waitForEvent` on `websocket` events can be powerful.

By combining controlled backend simulation with precise client-side event observation and robust assertions, we can comprehensively test WebSocket reconnection scenarios in Playwright, ensuring application resilience.

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

[The Hook]
"Testing WebSocket reconnection is absolutely critical for the reliability of any real-time application, particularly when considering the dynamic network conditions users face daily. Our automation strategy must robustly simulate these real-world disruptions to ensure a seamless user experience and prevent data loss, which directly impacts our engineering efficiency and product trust."

[The Core Execution]
"When approaching this in Playwright, the primary challenge is effectively simulating a server-side WebSocket disconnect, which isn't natively handled by

How do you test WebSocket reconnection 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?