test-driven-development

Write one minimal failing test for a single behavior, run it and confirm it fails for the expected reason, write the simplest code to make it pass, verify all tests pass, then refactor while keeping tests green. Repeat for each new behavior.

Tests written after code pass immediately, which proves nothing about whether they test the right thing. Watching a test fail first confirms it actually detects the missing behavior and is not biased by the existing implementation.

Only for throwaway prototypes, generated code, or configuration files, and only after asking your human partner. Exploration is fine, but the exploratory code should be discarded and rewritten test-first.

Delete the implementation and start over with a failing test. Keeping it as reference leads to adapting it, which is effectively testing after. The sunk time is already gone; unverified code is technical debt.

An immediately passing test means it is testing existing behavior or testing nothing meaningful. Fix the test so it fails for the expected reason, such as a missing feature, before writing any implementation code.

Never assert on mock elements or test IDs; test the real component's behavior. Mock only after understanding the dependency's side effects, mirror complete real API responses, and move test-only cleanup into test utilities rather than production classes.