Test-Driven Development (TDD)

Follow the RED-GREEN-REFACTOR cycle for reliable, well-designed code.

The TDD Cycle

1. RED - Write a Failing Test First

Before writing any implementation code:

1. Understand the requirement: What behavior are you implementing?
2. Write a test that describes the expected behavior
3. Run the test: Verify it fails (RED)
4. Confirm the failure reason: The test should fail because the feature doesn't exist, not due to test errors

Example:
"I need to add a validateEmail function"
→ Write: test('validateEmail returns true for valid email', () => {...})
→ Run tests
→ See: "validateEmail is not defined" (RED - expected failure)

2. GREEN - Write Minimal Code to Pass

Write the simplest code that makes the test pass:

1. Focus only on passing the test: No extra features
2. Don't optimize yet: Clarity over cleverness
3. Run the test: Verify it passes (GREEN)
4. Celebrate briefly: You have working, tested code!

Example:
→ Write: function validateEmail(email) { return email.includes('@'); }
→ Run tests
→ See: All tests passing (GREEN)

3. REFACTOR - Improve the Code

Now that tests are green, improve the code:

1. Look for code smells: Duplication, unclear names, long functions
2. Refactor incrementally: Small, safe changes
3. Run tests after each change: Ensure they stay GREEN
4. Stop when clean: Don't over-engineer

Example:
→ Improve: Add proper regex validation
→ Run tests: Still GREEN
→ Add edge case tests: Empty string, missing domain
→ Implement edge cases: Keep GREEN

TDD Best Practices

• One behavior per test: Keep tests focused
• Descriptive test names: Tests document behavior
• Fast feedback loop: Run tests frequently
• Triangulate: Add more tests to drive better implementation
• Don't skip RED: Seeing the test fail first catches test bugs

When to Use TDD

• New feature implementation
• Bug fixes (write test that reproduces bug first)
• Refactoring (ensure tests exist first)
• API design (tests clarify the interface)

Common Pitfalls

• Writing implementation before tests
• Making too large a step (multiple behaviors at once)
• Skipping the refactor phase
• Testing implementation details instead of behavior