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 pass. Refactor only while tests stay green, then repeat 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 along with all existing tests.

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

Code written before tests was never verified by a failing test, so keeping it as reference biases you toward testing the implementation rather than the requirement. Deleting it and rewriting test-first produces tests that actually prove behavior.

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.