test-driven-development

Write one minimal failing test describing the desired behavior, run it to confirm it fails for the expected reason, then write the simplest code that passes. Refactor only after all tests are green, then repeat the cycle for the next behavior.

Write a test that reproduces the bug by asserting the correct behavior, then run it to watch it fail. Implement the minimal fix, confirm the test passes, and keep it as a regression guard so the bug cannot return.

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

A mock assertion only proves the mock exists, not that the real component works. Tests should assert the real component's observable behavior, mocking only slow or external dependencies while keeping the side effects the test depends on real.

Delete the implementation and start over with a failing test. Keeping it as reference or adapting it while writing tests biases the tests toward the existing code, so they may pass immediately without proving they catch real bugs.