FSD Frontend System Design

Part II — The Shield · Lesson 4.3

E2E and Automation Testing

In one lineA real browser walking a real user journey — few of them, and none of them flaky.

Where you've seen itThe checkout test that runs before every release, because that flow breaking costs money per minute.

  • Time17 min
  • DiagramUser journey with assertion points + flake sources
  • Chapter4 · Testing

Diagram

diagram
ONE JOURNEY, FOUR ASSERTION POINTS

  ┌────────┐   ┌────────┐   ┌────────┐   ┌─────────┐   ┌────────┐
  │ Search │──►│ Product│──►│  Cart  │──►│ Payment │──►│ Order  │
  └────────┘   └────────┘   └────────┘   └─────────┘   └────────┘
       ✓            ✓            ✓             ✓            ✓
   results       price        total       test card     order id
   visible      matches      updates      accepted      shown

  Cover the money path end to end.
  Do NOT enumerate 30 coupon edge cases here — that's 4.2's job.
diagram
WHERE FLAKE COMES FROM — and the actual fix

  cause                          ✗ bad fix          ✓ real fix
  ──────────────────────────────────────────────────────────────────
  element not ready yet          sleep(2000)        wait for the
                                                    assertion itself
  animation still running        sleep              disable animations
                                                    in test env
  shared/leftover data           re-run             seed fresh data
                                                    per test
  real 3rd-party API             retry              stub at the network
  parallel tests colliding       run serially       isolate accounts
  time/timezone dependence       ignore             freeze the clock
diagram
WHERE E2E RUNS — cost climbs left to right

  local dev  ──►  PR (smoke, ~5)  ──►  main (full, ~30)  ──►  prod
                                                              (synthetic
                                                               monitors)

How it works

  1. Pick journeys by revenue and blast radius, not by page count. Five to fifteen for most products.
  2. Seed state through the API, not the UI — logging in through the form on every test triples the runtime and adds a flake source.
  3. Wait on assertions, never on time. Modern runners (Playwright, Cypress) auto-retry assertions; sleep is always a bug.
  4. Stub third parties at the network layer; a payment sandbox outage should not fail your build.
  5. Run smoke on PRs, the full suite on main, and reuse the same specs as production synthetic monitors.
js
// Playwright: no sleeps, no manual retries
await page.getByRole('button', { name: 'Place order' }).click();
await expect(page.getByTestId('order-id')).toBeVisible();   // auto-waits

Trade-offs

StrengthCost
Catches wiring, routing, auth, and build issuesSlowest layer by 100×
Closest to real user experienceFlake risk is structural
Doubles as production monitoringFailures point at a screen, not a line

Visual regression belongs here too — screenshot diffing catches CSS breakage that no assertion describes. Budget for the review workload it creates.

Interview angle

"Your E2E suite is flaky. How do you fix it?"

  • Measure first: track per-test failure rate and quarantine anything under 99% within a day.
  • Attack the structural causes — shared data, real third parties, sleep-based waits, animation timing.
  • Then shrink the suite; most flaky E2E suites are covering things that belong two layers down.

Recap

  • Few tests, high value, real browser, money paths only.
  • Every sleep is a latent flake; wait on assertions instead.
  • Seed via API, stub third parties, isolate data per test.