FSD Frontend System Design

Part II — The Shield · Lesson 4.6

Test-Driven Development

In one lineWrite the failing test first — it forces you to design the interface before the implementation.

Where you've seen itBuilding a usePagination hook. Writing the test first makes you decide what it returns before you decide how it works.

  • Time14 min
  • DiagramRed → green → refactor cycle
  • Chapter4 · Testing

Diagram

diagram
THE CYCLE — minutes per lap, not hours

        ┌──────────────────┐
        │  1. RED          │  write the smallest failing test
        │  it must fail    │  ← if it passes, it tests nothing
        └────────┬─────────┘
                 ▼
        ┌──────────────────┐
        │  2. GREEN        │  simplest code that passes
        │  ugly is fine    │  ← hardcoding is allowed here
        └────────┬─────────┘
                 ▼
        ┌──────────────────┐
        │  3. REFACTOR     │  clean up, tests stay green
        │  no new behaviour│  ← the safety net you just built
        └────────┬─────────┘
                 │
                 └──────────► next case
diagram
WHY "RED FIRST" IS NOT CEREMONY

  test written AFTER code   → tests what the code DOES
                              (bugs included, happily asserted)
  test written BEFORE code  → tests what the code SHOULD do
                              and proves the test can fail
diagram
WHAT TDD ACTUALLY IMPROVES

  ✓ interface design     you're the first consumer of your own API
  ✓ small units          hard-to-test code is usually badly factored
  ✓ refactoring nerve    green suite = permission to change things
  ✗ not a substitute for integration or E2E coverage
  ✗ not free — expect it to feel slower for the first week

How it works

  1. Write one failing test naming the behaviour you want. Run it and watch it fail.
  2. Write the minimum code to pass — hardcode if that's genuinely minimal.
  3. Add the next case; the hardcoding stops working and forces the real implementation.
  4. Refactor with the suite green. Behaviour must not change in this step.
  5. Repeat in short laps. If a lap takes 20 minutes, the step was too big.

Trade-offs

TDD fitsTDD fights you
Pure logic, hooks, reducers, parsersExploratory UI and visual design
Bug fixes (reproduce first, then fix)Spikes and throwaway prototypes
Well-understood requirementsRequirements you're still discovering

The honest middle ground most teams land on: TDD for logic and bug fixes, test-after for UI composition, and always write the failing reproduction before fixing a reported bug — that one habit is non-negotiable and pays for itself immediately.

Interview angle

"Do you practise TDD?"

  • For logic-heavy code and for every bug fix, yes — a bug without a failing test first has no proof it's fixed.
  • For visual and exploratory UI work I build first and test the settled behaviour, because the interface is still moving.
  • The durable benefit isn't coverage, it's that untestable code is usually badly designed code, and TDD surfaces that immediately.

Recap

  • Red, green, refactor — and the red step is what proves the test works.
  • TDD is an interface design tool that produces tests as a by-product.
  • Reproduce every bug with a failing test before you fix it.