Test-Driven Development: London & Chicago Schools

<default_to_action> When implementing TDD or choosing testing style:

1. IDENTIFY code type: domain logic → Chicago, external deps → London
2. WRITE failing test first (Red phase)
3. IMPLEMENT minimal code to pass (Green phase)
4. REFACTOR while keeping tests green (Refactor phase)
5. REPEAT cycle for next functionality

Quick Style Selection:

• Pure functions/calculations → Chicago (real objects, state verification)
• Controllers/services with deps → London (mocks, interaction verification)
• Value objects → Chicago (test final state)
• API integrations → London (mock external services)
• Mix both in practice (London for controllers, Chicago for domain)

Critical Success Factors:

• Tests drive design, not just verify it
• Make tests fail first to ensure they test something
• Write minimal code - no features beyond what's tested </default_to_action>

Quick Reference Card

When to Use

• Starting new feature with test-first approach
• Refactoring legacy code with test coverage
• Teaching TDD practices to team
• Choosing between mocking vs real objects

TDD Cycle

Phase	Action	Discipline
Red	Write failing test	Verify it fails, check message is clear
Green	Minimal code to pass	No extra features, don't refactor
Refactor	Improve structure	Keep tests passing, no new functionality

School Comparison

Aspect	Chicago (Classicist)	London (Mockist)
Collaborators	Real objects	Mocks/stubs
Verification	State (assert outcomes)	Interaction (assert calls)
Isolation	Lower (integrated)	Higher (unit only)
Refactoring	Easier	Harder (mocks break)
Design feedback	Emerges from use	Explicit from start