TDD

Red. Green. Refactor. In that order, every time.

Hard Rules

• No production code without a failing test first.
• If production code was written before its test, delete it and start over with a failing test.
• Never skip the red step. A test that has never failed proves nothing.

Cycle

For each unit of behavior:

1. Red, Write a test for the next behavior. Run it. It must fail. Read the failure message, it should describe the missing behavior.
2. Green, Write the minimum production code to make the test pass. Nothing more. Run the test. Apply the verify skill.
3. Refactor, Clean up both test and production code. Run the test again. Still green? Done. Apply the verify skill.

Then pick the next behavior and repeat.

Rules for Each Step

Red:

• Test one behavior, not one function. Name the test after what the system should do, not what the function is called.
• The test must fail for the right reason, a missing method, wrong return value, unmet condition. Not a syntax error or import failure.
• If the test passes immediately, it's not testing new behavior. Delete it or pick a different behavior.

Green:

• Write the simplest code that passes. Hardcode if needed, the next test will force generalization.
• Do not add code "while you're in there." If it's not required by a failing test, it doesn't exist yet.
• Do not refactor during green. Pass first, clean second.

Refactor:

• Remove duplication between test and production code.
• Extract only when you see real duplication, not predicted duplication.
• Tests must still pass after every refactor move. Run them after each change.

Anti-Patterns