FSD Frontend System Design

Part II — The Shield · Lesson 4.1

Testing Overview

In one lineBuy the most confidence per second of CI time — that ratio decides the shape of your suite.

Where you've seen itA 40-minute pipeline that everyone learns to ignore. A suite nobody waits for provides zero protection, however thorough it is.

  • Time13 min
  • DiagramTest pyramid with cost and confidence axes
  • Chapter4 · Testing

Diagram

diagram
THE PYRAMID — and what each layer actually buys

                    ▲ confidence per test
                    │
         ┌──────────┴──────────┐
         │        E2E          │  10s–2min each · real browser
         │      (5–10%)        │  proves the FLOW works
         ├─────────────────────┤
         │    Integration      │  50–500ms each · components wired
         │      (20–30%)       │  proves the PIECES fit
         ├─────────────────────┤
         │        Unit         │  <10ms each · pure functions
         │      (60–70%)       │  proves the LOGIC is right
         └─────────────────────┘
                    │
                    ▼ cost, flakiness, time to debug
diagram
THE ICE-CREAM CONE — the failure mode to name in an interview

         ┌─────────────────────┐
         │        E2E          │  200 slow, flaky browser tests
         ├──────────┬──────────┤
         │  Integr. │             few
         └────┬─────┘
              │ Unit                almost none

  Symptoms: 40-min CI, "just re-run it", nobody trusts red builds.
diagram
WHAT EACH LAYER CANNOT SEE

  unit         ✗ wiring bugs, wrong props, bad API contract
  integration  ✗ routing, auth, real network, browser quirks
  E2E          ✗ edge-case logic (too slow to enumerate there)
  all three    ✗ visual regressions, a11y, performance budgets

How it works

  1. Push detail down. Every edge case belongs in the fastest layer that can express it.
  2. Push confidence up. A handful of E2E tests cover the money paths — signup, checkout, the one flow that must never break.
  3. Test behaviour, not implementation. A test that breaks on refactor is a maintenance cost, not a safety net.
  4. Budget CI time explicitly. Under 10 minutes to merge is the target; past that, developers route around the suite.
  5. Quarantine flaky tests immediately. One test that fails randomly teaches the team to ignore all red builds.

Trade-offs

More unit testsMore E2E tests
Fast, cheap, precise failuresSlow, expensive, vague failures
Miss integration and wiring bugsCatch what users actually hit
Refactor-fragile if over-mockedRefactor-resilient

Interview angle

"What's your testing strategy for a large frontend?"

  • Name the shape and the ratio, then justify it by CI time and debugging cost, not by dogma.
  • Cover money paths with E2E, everything else lower; add visual and a11y checks as separate gates.
  • State the flake policy — quarantine within a day — because that's what keeps a suite trusted.

Recap

  • Optimise for confidence per second of CI, not for coverage percentage.
  • Push detail down the pyramid, confidence up.
  • An ignored suite and no suite protect you equally.