tdd

Test-Driven Development

The Iron Law

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Production code written before its test is deleted, not kept. Delete means delete: not kept as a reference, not adapted while the test is written, not read one more time. Code you did not reconstruct from a failing test is untested code wearing a passing suite — the suite was written to fit what the code already does.

The law covers new features, bug fixes, and any change to existing behavior. The only exemptions are throwaway prototypes, generated code, and configuration, and each one requires the user to approve it out loud before you skip the cycle.

The cycle

Each step names what has to be true before the next one starts.

1. Find a reference. Look for a similar implementation already in this codebase before designing a new one. Done when: you have named the closest existing implementation, or established that none exists.

2. RED — write one failing test. One behavior per test. The name states the behavior, not the function. Exercise real code; mock only what cannot run inside a test. Done when: the test file exists and asserts a behavior no code implements yet.

3. Verify RED — run it and read the failure. Never skip this. A test you did not watch fail is a test you cannot trust. Done when: the run reports a failure (not an error) whose message names the missing behavior. It passed → it asserts behavior that already exists; rewrite it. It errored → fix the error and rerun until it fails for the intended reason.

4. GREEN — the smallest code that passes. No extra parameters, no adjacent cleanups, no capability the test does not demand. Done when: the target test passes, every other test still passes, and the output carries no new warnings.

5. REFACTOR — clean up while green. Remove duplication, improve names, extract helpers. Done when: the test results are unchanged and no behavior was added.

Then return to step 2 with the next behavior.