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 passes. Refactor only while all tests stay green, and repeat the cycle for each new behavior.

Name the production change each test should catch, derive expected values by hand rather than from the code under test, and assert real behavior instead of mock interactions. Finish with a mutation check: mentally break the code and confirm a test fails.

Exceptions are limited to throwaway prototypes, generated code, and configuration files, and only with explicit approval. Exploration is allowed, but the exploratory code must be discarded and the real implementation restarted test-first.

Use mocks only for slow or external dependencies, after learning the real method's side effects. Never assert on the mock itself, mirror the complete real data structure, and prefer integration tests with real components when mock setup grows large.

Delete the implementation and start over with a failing test. Keeping it as reference or adapting it while writing tests is effectively testing after the fact, which cannot prove the test catches the intended bug.