Development (TDD)

Core Rules (Non-Negotiable)

1. NEVER write production code without a failing test first
2. One behaviour per test
3. Write minimum code to make the test pass
4. Run tests and verify green state before proceeding

The TDD Cycle

🔴 RED    → Write ONE failing test
🟢 GREEN  → Write MINIMUM code to pass
✅ VERIFY → Run all tests, confirm green

Detailed Steps

🔴 RED — Write a Failing Test

1. Identify the next behaviour to implement
2. Write a test that specifies that behaviour
3. Run the test — it MUST fail
4. If it passes, you've either:
   • Written the wrong test, or
   • The behaviour already exists

🟢 GREEN — Make It Pass

1. Write the simplest code that makes the test pass
2. Do not write more than necessary
3. Do not refactor yet
4. Run the test — it MUST pass

✅ VERIFY — Confirm Green State

1. Run ALL tests, not just the new one
2. All tests must pass
3. If any fail, fix before continuing

What Counts as "Minimum Code"

• Hard-coded values are acceptable initially
• Duplication is acceptable initially
• "Ugly" code is acceptable initially
• Refactoring comes AFTER green using the refactoring skill

Test Naming

Use descriptive names that document behaviour:

// Good
"return empty list when library has no books"
"return error when member not found"

// Bad
"test1"
"testGetBooks"

Announcing Progress

🔴 RED → [behaviour being tested]
🟢 GREEN → Test passes
✅ VERIFY → All tests green

Common Mistakes

• Writing production code before the test
• Writing multiple tests before making any pass
• Refactoring while still red
• Skipping the verify step
• Writing tests that test implementation, not behaviour