Test-driven development

The loop

1. Red — write one test that fails for the right reason. Run it. A test that passes immediately is testing nothing; a test that errors instead of failing is testing the wrong thing.
2. Green — the smallest change that makes it pass. Ugly is fine here.
3. Refactor — clean up with the test green. If it goes red, you changed behavior, not structure.

Never skip step 1. Writing the test after the code produces a test shaped to the implementation, which is the one shape that cannot catch the implementation being wrong.

What to test

Test behavior at the boundary a caller actually depends on. For each unit ask: if this broke silently, who notices and how? If the answer is nobody, delete the code rather than test it.