test-driven-development

Follow the red-green-refactor cycle: write one minimal failing test, 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—they may test the wrong thing or mirror the implementation. Watching a test fail first proves it actually tests the intended behavior and forces edge-case discovery before coding.

Exceptions are limited to throwaway prototypes, generated code, and configuration files, and only with explicit approval from your human partner. Exploration is fine, but the exploratory code should be discarded and rewritten test-first.

An immediately passing test means you are testing existing behavior, not new functionality. Fix the test so it targets the missing feature, run it again, and confirm it fails for the expected reason before writing any implementation code.

Asserting on mock elements verifies the mock exists, not that the component works. Test real behavior instead—either unmock the component or assert on outcomes the real code produces, and mock only after understanding the dependency's side effects.

Write a failing test that reproduces the bug first, then follow the normal TDD cycle to fix it. The test proves the fix works and permanently prevents the bug from regressing.