TDD Philosophy — Why Write Tests Before Code

1// TRADITIONAL: implement first, discover design problems in production
2function processOrder(order) {
3  // 200 lines of implementation
4  // Two months later: discovered that order can be null, items can be empty,
5  // currency codes are not validated, and the return type was assumed wrong
6}
7
8// TDD: design problems discovered before a single line of implementation
9describe('processOrder', () => {
10  it('throws when order is null', () => {
11    expect(() => processOrder(null)).toThrow('Order is required');
12    // Already designed: order can be null, we need to handle it
13  });
14
15  it('returns total of zero for empty items array', () => {
16    const result = processOrder({ id: '1', items: [], currency: 'USD' });
17    expect(result.total).toBe(0);
18    // Already designed: empty items is valid, returns zero total
19  });
20
21  it('throws for unsupported currency codes', () => {
22    expect(() => processOrder({ id: '1', items: [], currency: 'XYZ' }))
23      .toThrow('Unsupported currency: XYZ');
24    // Already designed: currency validation required
25  });
26});
27// Only NOW do we write the implementation — with all edge cases already specified

1// LAW 1 VIOLATION: writing production code without a test
2function formatCurrency(amount: number, currency: string): string {
3  // This code has no test requiring it — TDD violation
4  return new Intl.NumberFormat('en-US', { style: 'currency', currency }).format(amount);
5}
6
7// LAW 1 CORRECT: test first
8// Step 1: Write failing test
9test('formats USD amount with $ symbol and 2 decimal places', () => {
10  expect(formatCurrency(49.99, 'USD')).toBe('$49.99');
11}); // FAILS — formatCurrency does not exist yet
12
13// Step 2: Write MINIMUM code to pass
14function formatCurrency(amount: number, currency: string): string {
15  return '$49.99'; // LAW 3 VIOLATION: hardcoded — but wait, this passes!
16}
17// This sounds absurd, but it forces you to write ANOTHER test that requires
18// generalising — the laws create pressure to write more tests
19
20// Step 3: Write next failing test
21test('formats EUR amount with € symbol', () => {
22  expect(formatCurrency(29.99, 'EUR')).toBe('€29.99');
23}); // FAILS — hardcoded '$49.99' does not match
24
25// Step 4: Generalise implementation
26function formatCurrency(amount: number, currency: string): string {
27  return new Intl.NumberFormat('en-US', { style: 'currency', currency }).format(amount);
28}
29// Both tests pass

1// HARD TO TEST — design problem: function does too much
2async function createUserAndSendWelcomeEmail(email: string, password: string) {
3  // Validation, DB insert, password hashing, email sending — all in one
4  // To test this, you need a real database AND a real email server
5  // OR you mock 8 different things
6}
7
8// TDD forces you to feel the pain immediately — this function is painful
9// to write tests for, which signals you should split it.
10
11// EASY TO TEST — design improvement: separated responsibilities
12function validateUserInput(email: string, password: string): ValidationResult {
13  // Pure function: no I/O, easy to test
14}
15
16async function hashPassword(password: string): Promise<string> {
17  // One responsibility, easy to test
18}
19
20async function saveUser(user: NewUser, repo: UserRepository): Promise<User> {
21  // Injected repository: easy to mock in tests
22}
23
24async function sendWelcomeEmail(to: string, emailService: EmailService): Promise<void> {
25  // Injected service: easy to mock in tests
26}
27
28// Each function is independently testable
29// TDD discovered this design by making the pain of testing the original obvious

1Debugging time breakdown (typical project without TDD):
2Week 1:   Write feature (3h) + debug later (0h) = 3h
3Week 4:   Related change breaks feature, debug (2h) = 2h overhead
4Week 8:   Another change, more debugging (1h) = 1h overhead
5Total:    3h feature + 3h debugging = 6h
6
7With TDD:
8Week 1:   Write feature with TDD (5h, includes tests) = 5h
9Week 4:   Change breaks test, fix immediately (10 min) = 0.2h overhead
10Week 8:   Change breaks test, fix immediately (10 min) = 0.2h overhead
11Total:    5h feature + 0.4h debugging = 5.4h
12
13Breakeven: ~Week 4. After that, TDD saves time every sprint.

1// The 'debugging avoided' is not just time — it is also:
2// - No production incidents from regression bugs
3// - No customer-facing failures traced to untested edge cases
4// - No 2am on-call pages for bugs tests would have caught
5// - Confident refactoring that does not require manual QA regression
6
7// Example: a bug found by a test vs found in production
8// Found by test:
9//   Test fails → 5 minutes to diagnose (test name tells you exactly what broke)
10//   → 15 minutes to fix → commit
11
12// Found in production:
13//   Customer reports issue → 30 minutes to reproduce
14//   → 1 hour to trace through logs → 30 minutes to find root cause
15//   → 15 minutes to fix → deploy → verify → 2.5 hours total
16
17// One production bug caught by TDD saves the equivalent of writing
18// 3-5 hours of test code. Bugs caught in production are 5-10x more
19// expensive to fix than bugs caught in development.

1// Target: implement slugify(text) — converts 'Hello World' to 'hello-world'
2
3// STEP 1: RED — write a failing test
4test('converts text to lowercase with hyphens', () => {
5  expect(slugify('Hello World')).toBe('hello-world');
6});
7// Run: FAIL — slugify is not defined
8
9// STEP 2: GREEN — minimum code to pass
10export function slugify(text: string): string {
11  return text.toLowerCase().replace(/\s+/g, '-');
12}
13// Run: PASS ✅ (3 seconds of implementation)
14
15// STEP 3: RED — next test to drive more behaviour
16test('removes special characters', () => {
17  expect(slugify('Hello, World!')).toBe('hello-world');
18});
19// Run: FAIL — comma and exclamation mark not handled
20
21// STEP 4: GREEN — extend implementation
22export function slugify(text: string): string {
23  return text.toLowerCase()
24    .replace(/[^a-z0-9\s-]/g, '') // remove special chars
25    .replace(/\s+/g, '-')          // spaces to hyphens
26    .replace(/-+/g, '-');           // collapse multiple hyphens
27}
28// Run: Both tests PASS ✅
29
30// STEP 5: RED — edge cases
31test('handles leading and trailing spaces', () => {
32  expect(slugify('  Hello World  ')).toBe('hello-world');
33});
34
35test('handles multiple spaces', () => {
36  expect(slugify('Hello   World')).toBe('hello-world');
37});
38// Run: FAIL on first test (leading/trailing hyphens remain)
39
40// STEP 6: GREEN — handle trimming
41export function slugify(text: string): string {
42  return text.trim().toLowerCase()
43    .replace(/[^a-z0-9\s-]/g, '')
44    .replace(/\s+/g, '-')
45    .replace(/-+/g, '-')
46    .replace(/^-|-$/g, ''); // remove leading/trailing hyphens
47}
48// Run: All 4 tests PASS ✅
49
50// Total time: ~8 minutes, complete specification, full coverage