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 to make it pass. Refactor only while all tests stay green, then repeat the cycle for the next behavior.

Write a test that reproduces the bug, such as asserting that an empty email returns an error, and run it to watch it fail. Then implement the minimal fix and confirm the test passes without breaking other tests.

Tests written after code pass immediately, which proves nothing about whether they test the right behavior. Watching a test fail first confirms it actually exercises the missing feature rather than a typo or existing behavior.

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 before restarting with TDD.

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. Fix these by testing real behavior and mocking minimally at the right level.