test-driven-development

Write one minimal failing test describing the desired behavior, run it to confirm it fails for the right reason, then write the simplest code that makes it pass. 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 expected behavior, then run it to confirm it fails. Implement the minimal fix, verify the test passes and no other tests break, which also prevents future regressions.

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.

Code written before a failing test cannot be trusted because its tests would pass immediately and prove nothing. Keeping it as reference leads to adapting it during testing, which is effectively testing after implementation.

Common anti-patterns include asserting on mock elements instead of real behavior, adding test-only methods to production classes, mocking without understanding side effects, and creating incomplete mocks missing fields downstream code uses.