How to Test AI Chat Streaming UI with Playwright: Complete 2026 Guide

3. Mocking an SSE Stream with page.route()

The foundation of every AI chat streaming test is intercepting the chat API endpoint and returning a controlled Server-Sent Events response. Playwright’s page.route() method intercepts any matching network request and lets you fulfill it with a custom response. For streaming, you return a ReadableStream body that emits SSE-formatted chunks over time.

The OpenAI-compatible SSE format sends each chunk as a JSON object prefixed with data: and terminated with two newlines. The final signal is data: [DONE], which tells the client the stream is complete. Your mock must replicate this format exactly, because most chat UI libraries (Vercel AI SDK, LangChain, custom implementations) parse it strictly and will silently drop malformed chunks.

Notice that mockSSEStreamtakes an array of tokens, not a single string. This lets you control exactly where the “word boundaries” fall in the stream. In production, LLM APIs send tokens that rarely align with word boundaries (you might receive "Hel", then "lo, how"), so testing with irregular splits helps catch rendering bugs that only appear with real API responses. For the initial test, clean word-aligned tokens are fine; later scenarios use realistic splits.

4. Verifying Token-by-Token Rendering

The previous scenario waited for the final message. This scenario verifies that tokens actually render incrementally, which is the whole point of a streaming UI. A broken streaming implementation might buffer the entire response and render it at once, which technically passes a “final text matches” assertion but delivers a poor user experience. To catch this, you need to observe the DOM during the stream, not just after it.

The approach uses slower token timing (200ms per token) and polls the message element’s text content at multiple checkpoints during the stream. If the UI renders tokens incrementally, you will see partial text at each checkpoint. If it buffers, all checkpoints will show either empty or the full response.

The key assertion is the mid-stream check: after 450ms with 200ms per token, approximately two tokens should have rendered. The test confirms the early text includes the first two tokens but not the final token. This proves the UI streams tokens incrementally rather than buffering. In production, you would also verify that the cursor or caret animation is active during streaming, which we cover in the typing indicator scenario.

test('tokens render incrementally', async ({ page }) => {
  const tokens = ['The ', 'answer ', 'to ', 'your ',
                   'question ', 'is ', '42.'];
  await page.route('**/api/chat', (route) =>
    mockSSEStream(route, { tokens, delayMs: 200 })
  );
  await page.goto('/');
  await page.getByPlaceholder('Type a message')
    .fill('What is the answer?');
  await page.getByRole('button', { name: 'Send' }).click();
  const msg = page.locator(
    '[data-testid="assistant-message"]').last();
  await page.waitForTimeout(450);
  const earlyText = await msg.textContent();
  expect(earlyText).toContain('The answer');
  expect(earlyText).not.toContain('42.');
  await expect(msg).toContainText(
    'The answer to your question is 42.');
});

5. Cancel Mid-Stream with AbortController

Every production AI chat interface needs a “Stop generating” button. When the user clicks it, the frontend calls AbortController.abort(), which cancels the fetch request, closes the SSE connection, and stops rendering new tokens. Testing this correctly requires verifying three things: the network connection actually closes, the partial message is preserved in the DOM, and the UI returns to an idle state where the user can send a new prompt.

The challenge is timing. You need the stream to be actively sending tokens when the cancel button is clicked. If the stream finishes before your test clicks Stop, you are testing a no-op. The solution is to use a longer token list with generous delays, ensuring the stream is still active when the click happens.

A subtle bug to watch for: some implementations clear the partial message on abort, showing a blank assistant bubble. Others freeze the typing indicator animation but never remove it, leaving a permanently “thinking” UI. Both are real bugs found in production chat applications. The test above catches the first by asserting the partial text is preserved, and the typing indicator scenario (section 6) catches the second.

6. Typing Indicator and Loading States

The typing indicator (often a pulsing dots animation or a blinking cursor) is the user’s primary feedback that the AI is processing their request. It should appear immediately after the user sends a prompt (before any tokens arrive), remain visible during streaming, and disappear once the stream completes. A missing or stuck typing indicator is one of the most commonly reported UX bugs in chat applications.

The 300ms delay per token is intentional. With faster timing, the stream might complete before Playwright can assert on the typing indicator, making the test flaky. Slower tokens give the test a reliable observation window. In your CI configuration, you can reduce the delay for speed, but during development, keep it generous enough for visual debugging with --headed mode.

7. Markdown Rendering and Auto-Scroll During Streaming

AI assistants frequently respond with markdown: headings, bullet lists, code blocks with syntax highlighting, bold text, and inline code. The renderer must handle partial markdown gracefully. A code fence that opens with ```typescript in one chunk should not crash the parser before the closing fence arrives seconds later. Similarly, the chat container should auto-scroll to keep the latest content visible, but it must stop auto-scrolling if the user manually scrolls up to read earlier messages.

The auto-scroll tests verify a subtle but important UX contract. When the user is passively watching the stream, the container scrolls down automatically. When the user scrolls up to review previous content, the auto-scroll must pause so it does not yank the viewport away from what the user is reading. Many chat implementations get this wrong by either never auto-scrolling (bad for long responses) or always auto-scrolling (bad for review).

8. Retry on Error and Rate Limiting UI Feedback

Streaming connections fail. The LLM provider returns a 429 (rate limited), the connection drops mid-stream, or the server returns a 500 error after sending partial tokens. A robust chat UI handles all three cases gracefully: showing an error message, offering a retry button, and preserving any partial content that was already rendered. Testing these error paths requires mocking failures at different points in the stream lifecycle.

test('retry after error resends prompt', async ({ page }) => {
  let callCount = 0;
  await page.route('**/api/chat', async (route) => {
    callCount++;
    if (callCount === 1) {
      await route.fulfill({
        status: 500,
        body: JSON.stringify({
          error: { message: 'Internal error' }
        }),
      });
    } else {
      await mockSSEStream(route, {
        tokens: ['Here ', 'is ', 'your ', 'answer.'],
        delayMs: 30,
      });
    }
  });
  await page.goto('/');
  await page.getByPlaceholder('Type a message')
    .fill('Help me');
  await page.getByRole('button', { name: 'Send' }).click();
  await expect(page.getByRole('button',
    { name: /retry/i })).toBeVisible();
  await page.getByRole('button', { name: /retry/i }).click();
  const msg = page.locator(
    '[data-testid="assistant-message"]').last();
  await expect(msg).toContainText('Here is your answer.');
});