test-driven-development

Test-driven development

Write the test. Watch it fail. Write minimal code to pass.

Core principle: if you didn't watch the test fail, you don't know if it tests the right thing.

Iron law: no production code without a failing test first.

RED → GREEN → REFACTOR

RED — write the failing test

One minimal test of the behavior you want. Concrete inputs and expected outputs.

Verify it fails for the right reason

A test that errors with "function not defined" is correct red. A test that errors with "module not found" or a typo is broken — fix it before proceeding. A test that passes immediately is not testing the new behavior — fix the test.

GREEN — minimal code

Smallest implementation that makes the test pass. Resist abstractions. If returning a hardcoded value passes the test, return the hardcoded value — the next test will force generalization.

REFACTOR — clean up

Tests stay green. Rename for clarity, extract obvious duplication, remove dead code. No behavior changes.

Next

One test at a time. New behavior → new test → red → green → refactor.

When to use

• New features
• Bug fixes (the failing test is the bug reproduction)
• Refactoring (existing tests are the safety net; if they don't exist, write characterization tests first)
• Behavior changes

Exceptions (ask first)

• Throwaway prototypes
• Generated code
• Configuration files

"Skip TDD just this once" is a rationalization. Stop.

Anti-patterns

• Writing implementation before test. Delete it. Start over from the test. No "keep it as reference," no "adapt it."
• Skipping the failure verification. A green-from-the-start test isn't a test, it's a comment.
• Multiple tests per cycle. One at a time. Multiple tests = multiple things failing = you can't tell which fix moved which test.
• Refactoring red tests. Red means "not yet working." Make it green first; then refactor.