SSR Testing

Purpose

SSR Testing focuses on validating the correctness and robustness of server-side rendering (SSR) and partial hydration behaviors within the system’s React application environment. This subtopic addresses the need to ensure that the SSR process correctly renders initial content on the server, and that subsequent client-side hydration — including partial hydration with React Suspense — updates the UI seamlessly without errors or inconsistencies.

This testing is critical to guarantee that the SSR support delivers fast initial page loads, preserves UI consistency, and integrates well with advanced React features such as streaming and suspense, thereby enhancing user experience and performance.

Functionality

The core functionality involves end-to-end (E2E) test scenarios that simulate real browser environments to verify:

The tests work by navigating to specially prepared example pages (./basic-ssr and ./partially-hydrate) that implement the respective SSR and hydration scenarios, then asserting the presence of specific text nodes reflecting rendering states and data histories.

Example Test Flow Snippet

await page.goto('./basic-ssr', { waitUntil: 'commit' })
await expect(page.getByText('result:undefined')).toBeVisible()
await expect(page.getByText('result:SSR Works')).toBeVisible()
await expect(page.getByText('history:[null,"SSR Works"]')).toBeVisible()
expect(log).toHaveLength(0)

This snippet illustrates checking initial server-rendered placeholders (result:undefined), verifying that hydration updates the UI (result:SSR Works), and confirming no runtime errors occurred (log length is zero).

Integration

SSR Testing is tightly integrated with the parent topic Server-Side Rendering and Streaming, serving as the quality assurance layer that verifies the implementation’s correctness. It complements other subtopics such as Partial Hydration by directly validating the behaviors demonstrated there, and it interacts indirectly with core data fetching and suspense mechanisms by testing their runtime effects in an SSR context.

By automating verification of both full SSR and incremental hydration flows, this testing subtopic ensures that the SSR infrastructure and streaming support operate reliably across various scenarios, providing confidence to developers and users.

Diagram

sequenceDiagram
    participant TestRunner as Playwright Test
    participant Browser as Headless Browser
    participant SSRPage as SSR Example Page
    participant Client as React Client Hydration

    TestRunner->>Browser: Navigate to SSR Page
    Browser->>SSRPage: Load server-rendered HTML
    SSRPage-->>Browser: Initial HTML with placeholders (e.g., result:undefined)
    Browser->>Client: Execute hydration scripts
    Client-->>Browser: Update UI with fetched data (e.g., result:SSR Works)
    Browser->>TestRunner: Assert UI states and no error logs

This sequence diagram highlights the key stages of SSR testing: navigation, server-rendered content loading, client hydration, UI update, and assertion, capturing the essential flow validated by the tests.