test-driven-development

Write one minimal test describing the desired behavior, run it and watch it fail for the expected reason, then write the simplest code that makes it pass. Refactor only after the test is green, and repeat the cycle for the next behavior.

Red means writing a failing test, green means writing minimal code to pass it, and refactor means cleaning up while keeping tests green. Verifying the failure and the pass at each step is mandatory, never skipped.

Write tests before implementation. Tests written after pass immediately, which proves nothing about whether they catch the right bug. If code was written first, delete it and reimplement from the failing test.

Only for throwaway prototypes, generated code, or configuration files, and only after asking your human partner. Exploration is fine, but the exploratory code must be discarded and the real work restarted with TDD.

An immediately passing test means you are testing existing behavior, not the new feature. Fix the test so it fails because the feature is missing, then implement until it passes.

Name the production change that would make the test fail before writing it, derive expected values by hand rather than with the code under test, and assert on real behavior instead of mocks. Run a mental mutation check before finishing.