test-driven-development

Write one minimal failing test describing the desired behavior, run it and confirm it fails for the expected reason, write the simplest code that makes it pass, verify all tests pass, then refactor while keeping tests green. Repeat for each new behavior.

Name the specific production change that would make each test fail, derive expected values by hand rather than reusing the code under test, and assert on real behavior instead of mock interactions. Finish with a mutation check: mentally break the code and confirm a test catches it.

Only for throwaway prototypes, generated code, or configuration files, and only with explicit approval from your human partner. Exploratory coding is allowed, but the exploration must be discarded and the real implementation restarted with TDD.

Mock only slow or external operations after learning the real method's side effects, keeping everything the test depends on real. Never assert on the mock itself, mirror the complete real data structure, and prefer integration tests with real components when mock setup grows large.

Tests written after implementation pass immediately, which proves nothing about whether they test the right thing. Watching a test fail first confirms it can catch the bug, and test-first design keeps interfaces simple because hard-to-test code signals unclear design.