Testing Frontend & E2E

6 · Mocking the network with MSW

Your component calls fetch("/api/ask"). In a test you don't want a real backend — it'd be slow, require a running server, and give different answers each run. You need to intercept that request and return a canned response. The 2026 standard for this is MSW (Mock Service Worker) v2.

The old approach was to monkey-patch global.fetch with a stub. That's brittle: you're faking the function, so your test passes even if you call the wrong URL, send the wrong body, or your real code switches from fetch to axios. MSW intercepts at the network layer — it doesn't care which client you use, and it matches on the actual URL, method, and body. Your application code runs completely unchanged; it genuinely makes a request, MSW just answers it.

src/test/handlers.ts

import { http, HttpResponse } from "msw"

export const handlers = [
  http.post("/api/ask", async ({ request }) => {
    const body = await request.json() as { question: string }
    return HttpResponse.json({
      answer: f`Refunds are processed within 14 days.`,
      sources: [{ doc: "policy.pdf", page: 3 }],
    })
  }),
]

Wire a Node server into your setup file so every test gets the handlers automatically, and reset between tests so one test can't leak into another:

src/test/setup.ts

import "@testing-library/jest-dom/vitest"
import { afterAll, afterEach, beforeAll } from "vitest"
import { setupServer } from "msw/node"
import { handlers } from "./handlers"

export const server = setupServer(...handlers)

beforeAll(() => server.listen({ onUnhandledRequest: "error" }))
afterEach(() => server.resetHandlers())   // undo per-test overrides
afterAll(() => server.close())

Inside a single test you can override a handler — to simulate an error, say — and resetHandlers() wipes it afterwards:

import { http, HttpResponse } from "msw"
import { server } from "./test/setup"

it("shows an error when the API fails", async () => {
  server.use(
    http.post("/api/ask", () => new HttpResponse(null, { status: 500 }))
  )
  // …render, ask, then assert the error message appears
})

7 · Testing a custom hook

Most logic in a modern React app lives in custom hooks. You could test a hook only through a component that uses it — and often that's fine — but when a hook is gnarly enough to deserve focused tests, RTL gives you renderHook. It mounts the hook in a throwaway component and hands you back its return value.

useAsk.test.ts

import { renderHook, waitFor } from "@testing-library/react"
import { act } from "react"
import { useAsk } from "./useAsk"

it("loads an answer for a question", async () => {
  const { result } = renderHook(() => useAsk())

  expect(result.current.answer).toBeNull()

  await act(async () => {
    await result.current.ask("What is the refund policy?")
  })

  await waitFor(() =>
    expect(result.current.answer).toMatch(/refunds/i)
  )
})

result.current always points at the hook's latest return value — so after an update you re-read result.current, you don't hold a stale reference. Wrap any call that triggers a state update in act() so React flushes the change before you assert. MSW intercepts the hook's fetch exactly as it did for components — the mock layer doesn't care whether the request came from a component or a hook.

8 · Playwright E2E & CI

Everything so far runs in jsdom — a fake DOM, no real rendering engine, no real network. For the top of the pyramid you want a real browser running your real app. Playwright is the 2026 standard: it drives Chromium, Firefox, and WebKit, and it's built to defeat the historical curse of E2E testing — flakiness.

npm init playwright@latest   # scaffolds config, installs browsers

A Playwright test reads almost like prose. You navigate, locate, act, and assert:

e2e/ask.spec.ts

import { test, expect } from "@playwright/test"

test("a user can ask a question", async ({ page }) => {
  await page.goto("/")
  await page.getByRole("textbox", { name: "Ask a question" })
    .fill("What is the refund policy?")
  await page.getByRole("button", { name: "Send" }).click()
  await expect(page.getByText(/refunds are processed/i)).toBeVisible()
})

Notice the same getByRole philosophy carries over — Playwright deliberately mirrors RTL's accessible locators so the skill transfers. A few ideas that make Playwright reliable where older tools (Selenium, the old Cypress habits) were flaky:

Saving auth / storage state. Logging in through the UI before every test is slow. Instead, log in once, save the cookies and localStorage to a file, and reuse it. This is the single biggest E2E speed win:

e2e/auth.setup.ts

import { test as setup } from "@playwright/test"

setup("authenticate", async ({ page }) => {
  await page.goto("/login")
  await page.getByLabel("Email").fill("test@docchat.ae")
  await page.getByLabel("Password").fill("secret")
  await page.getByRole("button", { name: "Sign in" }).click()
  await page.waitForURL("/")
  // persist cookies + localStorage to disk
  await page.context().storageState({ path: "e2e/.auth/user.json" })
})

Then in playwright.config.ts point your project at that stored state with use: { storageState: "e2e/.auth/user.json" }, and every test starts already logged in.

The trace viewer. Configure use: { trace: "on-first-retry" }. When a test fails in CI, download the trace artifact and open it with npx playwright show-trace trace.zip. You'll see a filmstrip of the run, every action, network call, and a DOM snapshot at each step — debugging a CI-only failure goes from guesswork to obvious.

9 · Build: testing DocChat's chat

First the integration test. It exercises the component and its request code, with the network deterministically mocked:

ChatBox.test.tsx

import { render, screen } from "@testing-library/react"
import userEvent from "@testing-library/user-event"
import { http, HttpResponse } from "msw"
import { server } from "./test/setup"
import { ChatBox } from "./ChatBox"

it("answers a typed question", async () => {
  server.use(
    http.post("/api/ask", () =>
      HttpResponse.json({ answer: "Refunds are processed within 14 days." })
    )
  )
  const user = userEvent.setup()
  render(<ChatBox />)

  await user.type(
    screen.getByRole("textbox", { name: "Ask a question" }),
    "What is the refund policy?",
  )
  await user.click(screen.getByRole("button", { name: "Send" }))

  // the answer arrives asynchronously — findBy waits for it
  expect(
    await screen.findByText(/refunds are processed within 14 days/i)
  ).toBeInTheDocument()
})

Read what this test does and does not do. It never inspects component state, never checks a class name, never asserts that fetch was called. It does exactly what a user does — type, click, read the answer — so it'll survive any refactor that keeps that behaviour intact, and fail only when a user would actually be let down.

Now the Playwright happy-path, exercising the real upload form, the document list, and the chat box together in a browser:

e2e/upload-and-ask.spec.ts

import { test, expect } from "@playwright/test"
import path from "node:path"

test("upload a document then ask about it", async ({ page }) => {
  await page.goto("/")

  // 1 · upload via the file input
  await page.getByLabel("Upload a document")
    .setInputFiles(path.join(__dirname, "fixtures/policy.pdf"))

  // 2 · it appears in the document list (auto-waits)
  await expect(
    page.getByRole("list", { name: "Documents" })
  ).toContainText("policy.pdf")

  // 3 · ask a question about it
  await page.getByRole("textbox", { name: "Ask a question" })
    .fill("What is the refund policy?")
  await page.getByRole("button", { name: "Send" }).click()

  // 4 · the answer renders (assertion retries until visible)
  await expect(page.getByText(/refund/i)).toBeVisible()
})

This single test, slow as it is, proves the whole feature is wired together: the upload endpoint, the list re-render, the ask endpoint, the RAG pipeline, the chat rendering. That's the broad confidence the integration tests can't give you — and why one good E2E test per critical journey earns its keep.

10 · Check yourself

Answer from memory — retrieval is what moves this from "I read it" to "I know it".