Test-Driven Development

Overview

Write a failing test before writing the code that makes it pass. For bug fixes, reproduce the bug with a test before attempting a fix. Tests are proof — "seems right" is not done. A codebase with good tests is an AI agent's superpower; a codebase without tests is a liability.

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Write implementation code before the test? Delete it and start over. Do not keep it as reference, adapt it while writing the test, or argue that manual testing, sunk cost, a deadline, or a behavior-preserving refactor makes this case different. Violating the letter of the rule violates its purpose.

This applies to new features, bug fixes, refactors, behavior changes, and characterization tests for previously untested code. The only exceptions are pure documentation or configuration changes with no behavioral impact, generated code, and throwaway prototypes; ask the human partner when classification is unclear.

Already-Written Implementation: STOP

If you already wrote a new implementation without first watching a test fail, you are in a TDD violation. Do not write tests against that implementation and call it characterization, do not keep it as a reference, and do not commit it because the deadline is close. Delete the implementation, write the smallest behavior test, verify RED, then implement again from that test.