tdd-implement

TDD Implementation

The goal is to write honest tests that define behavior, implement the minimum code to pass them, then clean up. No rigging tests to pass. No over-engineering beyond what the tests require.

Step 1: Understand what you're building

Before writing a single test, be clear on:

• What problem does this solve?
• What are the acceptance criteria (from the issue, the user, or both)?
• What already exists in the codebase that you can build on?

# Discover existing patterns before planning
find src/ -name "*.test.*" -o -name "*.spec.*" | head -5  # How tests are structured here
find src/ -name "*.ts" -o -name "*.tsx" | xargs grep -l "[relevant term]" | head -5

Step 2: Define the MVP test plan

Write down 3-5 tests before touching implementation code. Each test should:

• Map directly to a specific acceptance criterion
• Test user-observable behavior, not internal implementation
• Answer: "Would a user notice if this broke?"

Tests to avoid:

• "renders without crashing"
• Prop-passing tests
• Checking that a function was called (unless it's the actual requirement)
• Exhaustive edge cases not in the acceptance criteria
• Tests that just re-assert a simple layout/visual fix — a box-sizing, padding, or margin tweak guards a value, not behavior, and only bloats the suite

Some fixes don't warrant a test at all

TDD doesn't mean every change gets a spec. When the entire fix is a one-line CSS/layout change, a config tweak, or a copy edit, a dedicated test (Playwright or unit) that pins a single property value is test bloat, not coverage — it makes the suite slower and noisier without catching a real regression class. For these, verify it live (run the app, observe the behavior) and lean on the existing visual-regression / smoke coverage instead of adding a new spec. Say so plainly ("one-line layout fix — no dedicated test") and move on rather than padding the suite to satisfy a checkbox. Reserve new tests for changes with real behavior a user could notice breaking.