How I'd lay out a frontend test suite for a team of five-plus engineers, why I put the trophy ahead of the pyramid, and what the CI numbers actually look like.
It was a Friday afternoon at the live-video creator platform I led engineering at, and five PRs landed in one batch migrating older Vue components to the new design system. CI passed. Deploy ran. About thirty minutes later, support pinged us: the bio section on creator profiles was missing. The DOM was fine, the CSS reset that the new system shipped was nuking padding-top on every <section>. The unit tests had no opinion on that. Neither did the few integration tests we had. The thing that would have caught it was a visual diff against a real route, and we didn’t have one yet.
That afternoon is the reason I have strong opinions about frontend testing for teams of five-plus engineers. The short version: the testing pyramid is the wrong shape for frontend, the trophy is the right shape, and you have to pick the layers that survive contact with a Friday merge train.
The pyramid says lots of unit tests, fewer integration, a handful of E2E. For backend that works. For frontend with components that render, fetch, and render again, it’s misleading. Most of the bugs I’ve shipped didn’t come from a function returning the wrong number. They came from the wrong thing being rendered, the wrong route loading, an API contract drifting, or a CSS reset eating layout. Unit tests catch almost none of those.
The trophy, from Kent C. Dodds, flips the priority: static checks at the base, then a fat middle of integration tests that render components against real DOM and mock the network, then a smaller layer of E2E. Visual regression sits alongside the integration tier as a separate axis. Unit tests are reserved for genuine pure logic, the formatters, the parsers, the date math.
For a team of five engineers shipping daily, that shape pays off. I’d rather review a PR with twelve component-integration tests than a hundred unit tests of internal helpers nobody calls directly.
Static first. TypeScript in strict mode, ESLint with the React and a11y rule sets, and tsc --noEmit running on every PR. If a contract change can be caught by types, you get it for free with no wall clock cost.
Integration is the bulk. React Testing Library plus MSW for the network. The test renders the component the user will actually use, MSW returns the response the API would actually return, and the assertion is against what the user would actually see. No shallow rendering. No reaching into internals.
import { render, screen, waitFor } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import { setupServer } from "msw/node";
import { http, HttpResponse } from "msw";
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
import { CommunityFeed } from "./CommunityFeed";
const server = setupServer(
http.get("/api/communities/:id/posts", ({ params }) => {
if (params.id === "boom") {
return HttpResponse.json({ error: "internal" }, { status: 500 });
}
return HttpResponse.json({
posts: [{ id: "p1", title: "hello", author: "Akin" }],
nextCursor: null,
});
}),
);
beforeAll(() => server.listen({ onUnhandledRequest: "error" }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());
function renderWithQuery(ui: React.ReactNode) {
const client = new QueryClient({ defaultOptions: { queries: { retry: false } } });
return render(<QueryClientProvider client={client}>{ui}</QueryClientProvider>);
}
test("renders posts and surfaces a retry on failure", async () => {
renderWithQuery(<CommunityFeed communityId="c1" />);
expect(await screen.findByText("hello")).toBeInTheDocument();
renderWithQuery(<CommunityFeed communityId="boom" />);
expect(await screen.findByRole("alert")).toHaveTextContent(/something went wrong/i);
await userEvent.click(screen.getByRole("button", { name: /retry/i }));
await waitFor(() => expect(screen.queryByRole("alert")).not.toBeInTheDocument());
});That’s the test I actually want my teammates writing. It exercises render, network, error, and recovery. It does not assert on a <div className="..."> somewhere in the tree, and it does not stub the query client.
Visual regression is the layer most teams skip and most teams regret skipping. Chromatic snapshots, or Playwright’s toHaveScreenshot, run against your highest-traffic routes. Thresholds tight. A reset that collapses every <section> lights up the build before merge.
E2E is the thin top. Playwright, a handful of user-critical journeys, real backend or a tightly-controlled fixture. Sign-in, the primary create flow, the primary read surface, billing. Three to seven specs. Not more.
import { test, expect } from "@playwright/test";
test.describe("creator can publish a post", () => {
test("from empty community to live post", async ({ page }) => {
await page.goto("/sign-in");
await page.getByLabel("email").fill(process.env.E2E_USER!);
await page.getByLabel("password").fill(process.env.E2E_PASS!);
await page.getByRole("button", { name: "sign in" }).click();
await expect(page).toHaveURL(/\/dashboard/);
await page.getByRole("link", { name: "community" }).click();
await page.getByRole("button", { name: "new post" }).click();
await page.getByLabel("title").fill("e2e smoke");
await page.getByLabel("body").fill("posted by playwright");
await page.getByRole("button", { name: "publish" }).click();
await expect(page.getByText("e2e smoke")).toBeVisible({ timeout: 10_000 });
});
});This is the spec that protects revenue. The other three hundred tests protect velocity. Different jobs.
A test suite the team can’t trust is worse than no suite at all. People stop reading the red and start re-running until green. The way I avoid that, roughly: split jobs by speed, fail fast on cheap checks, run heavy stuff in parallel shards.
name: ci
on: pull_request
jobs:
static:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- run: pnpm install --frozen-lockfile
- run: pnpm tsc --noEmit
- run: pnpm lint
unit_integration:
runs-on: ubuntu-latest
strategy:
fail-fast: false
matrix:
shard: [1, 2, 3, 4]
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- run: pnpm install --frozen-lockfile
- run: pnpm vitest run --shard=${{ matrix.shard }}/4
visual:
runs-on: ubuntu-latest
needs: static
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v4
- run: pnpm install --frozen-lockfile
- run: pnpm chromatic --exit-zero-on-changesCheap stuff first, four shards for integration, visual gated behind static so it doesn’t fire on a broken type. Concrete numbers from the most recent setup I tuned, on a team of around five engineers: static lands in roughly ninety seconds, sharded integration finishes inside four minutes wall clock, visual diffs come back in about six, and the Playwright smoke pack runs nightly plus on demand against staging. Total PR wall clock is somewhere between five and seven minutes. That’s the budget. If a layer pushes the suite past ten minutes, something has to come out, not in.
A second story from the creator-economy platform I spent the last few years at. We had a worker shipping at the edge for creator profile pages, locale-aware Open Graph metadata, the whole thing. A small refactor went out that supposedly tightened cache key composition. The new key dropped the locale segment. EU users started seeing US users’ previews on shared links. A German creator tweeted a screenshot, the thread had a couple hundred retweets in an hour.
The first wrong move was to nuke the Cloudflare cache. Three minutes later the same bad key produced the same wrong result. The real fix was a rollback of the worker plus a redeploy with the locale baked into the key, plus a deploy-time check that diffs cache-key composition against the previous deploy and refuses to merge when it changes without a flag. That deploy-time check is a test. It’s not a unit test, it’s not E2E, it’s a contract test that runs in CI. The trophy doesn’t care what you call it. It cares that the layer most likely to fail has a real check sitting between merge and prod. After that change, locale-aware OG never broke again. Around forty minutes of mis-shared previews was the price. The flag now requires PR review, and we shipped Chromatic across the top routes the same quarter, which is what caught a follow-on global-CSS regression a few weeks later.
Shallow rendering. enzyme is gone for a reason. Snapshot tests of entire component trees, they catch nothing and break on every refactor. One-line unit tests of trivial functions, just inline them. Coverage thresholds set to ninety-something percent, they push the team toward tests that exist to satisfy a number, not to catch bugs. I’d rather see eighty percent honest coverage than ninety-five percent of lines hit by tests that assert nothing useful.
A11y checks belong in the integration layer via jest-axe against the rendered DOM. Not a separate “a11y pass” later in the cycle. If a button has no accessible name, the test should fail in the same run as the layout test.
Thanks for reading. If you’ve got thoughts, send them my way.