TDD Cycle: Red, Green, Refactor - Test-Driven Development (TDD) | OneNoughtOne

0/290

System Design (LLD)Test-Driven Development (TDD)

Test-Driven Development (TDD)

LevelIntermediate

Duration90 mins

TopicTest-Driven Development (TDD)

1 / 4

TDD Cycle: Red, Green, Refactor

The Heartbeat of Test-Driven Development

There is a rhythm to Test-Driven Development that, once internalized, fundamentally transforms how you write software. This rhythm is captured in three simple words: Red, Green, Refactor. These words represent more than a technique—they embody a complete philosophy of software construction that has shaped how elite engineers approach code for over two decades.

The Red-Green-Refactor cycle is deceptively simple to describe but profoundly challenging to master. It asks you to invert your natural programming instincts: instead of writing code and then verifying it works, you first articulate precisely what "working" means through an executable specification—a test—and only then write the code to satisfy that specification.

What You Will Learn

By the end of this page, you will understand each phase of the TDD cycle with surgical precision. You'll know why the cycle works in this specific order, what traps await at each phase, and how the cumulative effect of thousands of these micro-cycles produces software with exceptional design quality. This isn't just process—it's architecture through incremental discovery.

Understanding the Cycle

The TDD cycle consists of three discrete phases, each with distinct purpose and characteristics. Understanding these phases deeply is essential because the power of TDD emerges from their precise execution and ordering.

The Three Phases:

Red Phase: Write a test that fails. This test defines a small, specific behavior you want to add to your system. The failure demonstrates that the behavior doesn't exist yet.

Green Phase: Write the minimum code necessary to make the test pass. This means doing the simplest possible thing that satisfies the test—nothing more.

Refactor Phase: Improve the code structure while keeping all tests passing. This is where design emerges and technical debt is actively managed.

Each cycle typically takes between 30 seconds and 5 minutes. Longer cycles suggest you're taking too big a step. The discipline is in keeping steps small and the cycle fast.

The Micro-Commitment Principle

Each TDD cycle represents a micro-commitment to functionality. By committing to tiny increments of verified behavior, you build confidence that compounds. One passing test is a fact. A hundred passing tests is a fortress. A thousand is an unmovable foundation.

TDD Cycle Visualization

Conceptual

┌─────────────────────────────────────────────────────────────┐
│                     TDD CYCLE                                │
│                                                              │
│    ┌─────────┐                                               │
│    │   RED   │  ←── Write a failing test                     │
│    │ (Fail)  │      (Define desired behavior)                │
│    └────┬────┘                                               │
│         │                                                    │
│         ▼                                                    │
│    ┌─────────┐                                               │
│    │  GREEN  │  ←── Write minimal code to pass               │
│    │ (Pass)  │      (Make it work, any way possible)         │
│    └────┬────┘                                               │
│         │                                                    │
│         ▼                                                    │
│    ┌──────────┐                                              │
│    │ REFACTOR │ ←── Improve structure, keep tests green      │
│    │ (Clean)  │     (Make it right)                          │
│    └────┬─────┘                                              │
│         │                                                    │
│         └──────────────► Back to RED                         │
│                                                              │
│    Typical cycle time: 30 seconds - 5 minutes                │
└─────────────────────────────────────────────────────────────┘

The Red Phase: Writing Failing Tests

The Red phase is where TDD begins—and where many practitioners stumble. Writing a failing test sounds trivial, but doing it well requires deep understanding of what tests should express and how they should fail.

The Purpose of Red:

The failing test serves multiple critical purposes:

Specification: It defines precisely what behavior you intend to implement
Verification of test infrastructure: A test must fail first to prove it can detect failure
Scope limitation: It forces you to think in small, implementable chunks
Documentation: It expresses intent for future readers

Critically, the test should fail for the right reason. If you're testing that a method returns 42, the failure should be "expected 42 but got null" or "method not found"—not a compilation error in unrelated code or a configuration failure.

Red Phase Principles

•Test one behavior only — Each test should verify exactly one logical behavior. If you find yourself using 'and' to describe what the test checks, you're testing too much.
•Name tests as specifications — Test names should read as behavior specifications: should_return_empty_list_when_no_items_added(), not testList() or test1().
•Start from the assertion — Write the assertion first, then work backwards to the setup. This keeps you focused on the behavior you're specifying.
•Watch it fail — Never proceed to green without seeing the test fail. This verifies your test is actually testing something.
•Fail for the right reason — Ensure the failure message relates to the behavior, not to syntax errors or missing infrastructure.

ShoppingCart.test.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// RED PHASE: Writing a failing test
// We're testing behavior that doesn't exist yet
 
describe('ShoppingCart', () => {
    // Test name reads as a specification
    it('should return zero total when cart is empty', () => {
        // Arrange: Set up the scenario
        const cart = new ShoppingCart();
        
        // Act: Perform the action
        const total = cart.getTotal();
        
        // Assert: Verify the expected outcome
        expect(total).toBe(0);
    });
    
    // Another specification-style test
    it('should return item price as total when single item added', () => {
        // Arrange
        const cart = new ShoppingCart();
        const item = new CartItem('Widget', 29.99);
        
        // Act
        cart.addItem(item);
        const total = cart.getTotal();
        
        // Assert
        expect(total).toBe(29.99);
    });
});
 
// At this point, running the test fails:
// "ReferenceError: ShoppingCart is not defined"
// or after creating empty class:
// "TypeError: cart.getTotal is not a function"
// 
// These are "right reason" failures - they tell us
// exactly what's missing.

The Danger of Skipping Red

If you write production code before the test, you lose the verification that your test actually tests what you think. A test that never failed might be testing nothing. Practitioners who skip red often discover later that their tests pass regardless of production code behavior—they're testing configuration, not logic.

The Green Phase: Making Tests Pass

The Green phase is deceptively challenging because it requires restraint. The goal is to make the test pass—nothing more. This means you might write code that looks incomplete, hardcoded, or even "wrong" to a conventional eye.

The Purpose of Green:

The green phase serves specific purposes that distinguish TDD from conventional development:

Rapid feedback: Get to a passing state quickly to verify your test is satisfiable
Defer design decisions: The simplest code delays premature abstraction
Expose missing tests: If obvious deficiencies aren't caught, your test suite has gaps
Maintain momentum: Quick wins sustain the rhythm of the cycle

The mantra of green is "make it work"—not "make it right" or "make it elegant." Elegance comes in refactor.

Green Phase Principles

•Write the simplest code that passes — If returning a hardcoded value passes the test, return the hardcoded value. Seriously.
•Don't anticipate future tests — Write only what this test demands. Future tests will demand more.
•Embrace "sinful" code — Duplication, magic numbers, poor names are all acceptable temporarily. They'll be fixed in refactor.
•One change, run tests — Make a small change, run the test. Stay in tight feedback loops.
•If you can't make it pass quickly, the step was too big — Go back to red and write a smaller test.

ShoppingCart.ts (Green Phase)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
// GREEN PHASE: Make the test pass with minimal code
// We're deliberately writing "incomplete" code
 
// First iteration: Make "empty cart returns zero" pass
class ShoppingCart {
    getTotal(): number {
        return 0;  // Hardcoded! And that's fine.
    }
}
 
// Test runs: ✓ should return zero total when cart is empty
// But wait, we have another failing test...
 
// Second iteration: Make "single item returns item price" pass
class CartItem {
    constructor(
        public readonly name: string,
        public readonly price: number
    ) {}
}
 
class ShoppingCart {
    private items: CartItem[] = [];
    
    addItem(item: CartItem): void {
        this.items.push(item);
    }
    
    getTotal(): number {
        // Still simple - no abstraction yet
        if (this.items.length === 0) {
            return 0;
        }
        return this.items[0].price;
    }
}
 
// Test runs: 
// ✓ should return zero total when cart is empty
// ✓ should return item price as total when single item added
 
// Notice: getTotal() doesn't sum multiple items!
// That's because we don't have a test for that YET.
// The next RED phase would add that test.

Why Hardcoding is Wisdom

Returning hardcoded values feels wrong, but it's strategically correct. It forces you to write additional tests that break the hardcoding. Each test you add triangulates towards the general solution. By the time enough tests exist, the general solution becomes obvious—and is thoroughly verified.

The Refactor Phase: Improving Structure

The Refactor phase is where design emerges. With a safety net of passing tests, you can confidently restructure code to improve clarity, reduce duplication, enhance naming, and introduce proper abstractions.

The Purpose of Refactor:

Refactoring serves essential purposes that make TDD sustainable:

Manage technical debt actively: The "sins" of green are paid off immediately
Discover abstractions: Patterns become visible across multiple implementations
Improve communication: Better names and structure make intent clearer
Prepare for the next feature: Clean code is easier to extend

The mantra of refactor is "make it right"—improve the implementation while preserving behavior.

The Golden Rule of Refactoring:

Change structure, not behavior. If your tests still pass after refactoring, you've preserved behavior. If they fail, you've introduced a bug or changed behavior that was intentional.

Refactor Phase Principles

•Remove duplication — If you see the same code twice, it's time to extract. DRY (Don't Repeat Yourself) applies strongly here.
•Improve names — Rename variables, methods, and classes to better express intent. Good names are documentation.
•Extract methods — Long methods should be broken into smaller, well-named pieces that tell a story.
•Introduce abstractions — When patterns emerge across tests, introduce interfaces or base classes that capture the abstraction.
•Run tests constantly — After each refactoring step, run the tests. Stay green throughout refactoring.
•Don't add behavior — Refactoring changes structure, not functionality. If you're adding features, return to red.

ShoppingCart.ts (Refactor Phase)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
// REFACTOR PHASE: Improve structure while keeping tests green
// Assume we've added more tests and the code has grown
 
// BEFORE REFACTOR (accumulated "sins" from green phases):
class ShoppingCart {
    private items: CartItem[] = [];
    
    addItem(item: CartItem): void {
        this.items.push(item);
    }
    
    getTotal(): number {
        // Duplication, no extraction, inline everything
        let total = 0;
        for (const item of this.items) {
            total = total + item.price * item.quantity;
            if (item.hasDiscount) {
                total = total - (item.price * item.quantity * item.discountPercent / 100);
            }
        }
        // Tax calculation inline
        const taxRate = 0.08;
        total = total + (total * taxRate);
        return Math.round(total * 100) / 100;
    }
}
 
// AFTER REFACTOR (structure improved, tests still pass):
 
class ShoppingCart {
    private static readonly TAX_RATE = 0.08;
    private readonly items: CartItem[] = [];
    
    addItem(item: CartItem): void {
        this.items.push(item);
    }
    
    getTotal(): number {
        const subtotal = this.calculateSubtotal();
        const withTax = this.applyTax(subtotal);
        return this.roundToMoney(withTax);
    }
    
    private calculateSubtotal(): number {
        return this.items.reduce(
            (sum, item) => sum + item.getEffectivePrice(),
            0
        );
    }
    
    private applyTax(amount: number): number {
        return amount * (1 + ShoppingCart.TAX_RATE);
    }
    
    private roundToMoney(amount: number): number {
        return Math.round(amount * 100) / 100;
    }
}
 
// CartItem now handles its own pricing logic
class CartItem {
    constructor(
        public readonly name: string,
        public readonly price: number,
        public readonly quantity: number = 1,
        private readonly discountPercent: number = 0
    ) {}
    
    getEffectivePrice(): number {
        const basePrice = this.price * this.quantity;
        return basePrice * (1 - this.discountPercent / 100);
    }
    
    get hasDiscount(): boolean {
        return this.discountPercent > 0;
    }
}
 
// All tests still pass! ✓
// But the code is now:
// - More readable (meaningful method names)
// - More maintainable (single responsibility)
// - More testable (each method can be tested independently)
// - More extensible (tax rates, rounding could vary)

The Cycle in Motion: A Complete Example

Let's watch multiple complete TDD cycles in action, building a feature from nothing to completion. We'll implement a simple StringCalculator that adds numbers from a string—a classic TDD kata.

The Kata:

Create a StringCalculator with a method add(string numbers) that:

Returns 0 for empty string
Returns the number for a single number
Returns the sum for two comma-separated numbers
(We'll add more requirements incrementally)

Watch how each cycle reveals the next requirement, and how the design emerges organically.

StringCalculator TDD Kata
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
// ═══════════════════════════════════════════════════════════
// CYCLE 1: Empty string returns zero
// ═══════════════════════════════════════════════════════════
 
// RED: Write failing test
describe('StringCalculator', () => {
    it('should return 0 for empty string', () => {
        const calculator = new StringCalculator();
        expect(calculator.add("")).toBe(0);
    });
});
// Run: ✗ ReferenceError: StringCalculator is not defined
 
// GREEN: Minimal implementation
class StringCalculator {
    add(numbers: string): number {
        return 0;
    }
}
// Run: ✓ All tests pass
 
// REFACTOR: Nothing to refactor yet - move on
 
// ═══════════════════════════════════════════════════════════
// CYCLE 2: Single number returns itself
// ═══════════════════════════════════════════════════════════
 
// RED: Write failing test
it('should return the number for single number input', () => {
    const calculator = new StringCalculator();
    expect(calculator.add("5")).toBe(5);
});
// Run: ✗ Expected 5, received 0
 
// GREEN: Minimal change
class StringCalculator {
    add(numbers: string): number {
        if (numbers === "") return 0;
        return parseInt(numbers);
    }
}
// Run: ✓ All tests pass
 
// REFACTOR: Code is simple enough - move on
 
// ═══════════════════════════════════════════════════════════
// CYCLE 3: Two numbers returns sum
// ═══════════════════════════════════════════════════════════
 
// RED: Write failing test
it('should return sum of two comma-separated numbers', () => {
    const calculator = new StringCalculator();
    expect(calculator.add("1,2")).toBe(3);
});
// Run: ✗ Expected 3, received NaN (parseInt of "1,2" is NaN)
 
// GREEN: Make it work
class StringCalculator {
    add(numbers: string): number {
        if (numbers === "") return 0;
        if (numbers.includes(",")) {
            const parts = numbers.split(",");
            return parseInt(parts[0]) + parseInt(parts[1]);
        }
        return parseInt(numbers);
    }
}
// Run: ✓ All tests pass
 
// REFACTOR: Now we see duplication and can improve
class StringCalculator {
    add(numbers: string): number {
        if (numbers === "") return 0;
        
        const numberStrings = numbers.split(",");
        return numberStrings
            .map(s => parseInt(s))
            .reduce((sum, n) => sum + n, 0);
    }
}
// Run: ✓ All tests still pass - refactoring preserved behavior
 
// ═══════════════════════════════════════════════════════════
// CYCLE 4: Handle any amount of numbers
// ═══════════════════════════════════════════════════════════
 
// RED: Test with more numbers
it('should handle any amount of numbers', () => {
    const calculator = new StringCalculator();
    expect(calculator.add("1,2,3,4,5")).toBe(15);
});
// Run: ✓ Already passes! Our refactoring handled it.
 
// This is the magic of TDD: our refactoring in cycle 3
// naturally extended to handle this case.
 
// REFACTOR: Add test but no code change needed
 
// ═══════════════════════════════════════════════════════════
// CYCLE 5: Handle newlines as delimiters
// ═══════════════════════════════════════════════════════════
 
// RED: New delimiter requirement
it('should handle newlines as delimiters', () => {
    const calculator = new StringCalculator();
    expect(calculator.add("1
2,3")).toBe(6);
});
// Run: ✗ Expected 6, received NaN
 
// GREEN: Quick fix
class StringCalculator {
    add(numbers: string): number {
        if (numbers === "") return 0;
        
        // Replace newlines with commas, then split
        const normalized = numbers.replace(/
/g, ",");
        return normalized
            .split(",")
            .map(s => parseInt(s))
            .reduce((sum, n) => sum + n, 0);
    }
}
// Run: ✓ All tests pass
 
// REFACTOR: Extract delimiter handling
class StringCalculator {
    private static readonly DELIMITERS = /[,
]/;
    
    add(numbers: string): number {
        if (this.isEmpty(numbers)) return 0;
        
        return this.parseNumbers(numbers)
            .reduce((sum, n) => sum + n, 0);
    }
    
    private isEmpty(input: string): boolean {
        return input === "";
    }
    
    private parseNumbers(input: string): number[] {
        return input
            .split(StringCalculator.DELIMITERS)
            .map(s => parseInt(s));
    }
}
// Run: ✓ All tests still pass
 
// Notice how design emerged:
// - Single responsibility for parsing
// - Configurable delimiters
// - Clear method names
// All through the TDD cycle!

Emergent Design

Notice how we never "designed" the StringCalculator upfront. We didn't create UML diagrams or architecture documents. The design emerged naturally from tests demanding behavior. Each refactoring made the code slightly more general, and the final result handles cases we didn't initially anticipate.

Common Anti-Patterns to Avoid

TDD seems simple but has subtle failure modes. Understanding anti-patterns helps you maintain the discipline that makes TDD effective.

TDD Anti-Patterns and Their Remedies
Anti-Pattern	Why It's Harmful	The Remedy
Writing tests after code	Tests become verification of implementation rather than specification of behavior. You're testing what you built, not what should be built.	Commit to writing tests first, even when tempted. The discomfort fades with practice.
Big steps (too much code before testing)	Long gaps between tests mean longer debugging when something fails. You lose the localization benefit.	If you can't make a test pass in 5 minutes, the step is too big. Write a smaller test.
Skipping refactor	Technical debt accumulates. The codebase becomes a sprawl of barely-working code. TDD without refactoring is just writing bad code with tests.	Make refactoring a non-negotiable part of each cycle. Block time for it.
Testing implementation, not behavior	Tests become brittle, breaking on every internal change. Refactoring becomes feared rather than embraced.	Focus tests on public APIs and observable behavior. Test what, not how.
Ignoring the failed test	Proceeding without seeing red means you don't know if the test actually tests anything.	Always run the test, verify it fails, understand why it fails.
Over-engineering in green	Adding abstractions before they're needed slows the cycle and creates premature generalization.	Write stupid simple code in green. Let patterns emerge through multiple tests.

The "Test Later" Trap

"I'll write tests later" is a promise that's rarely kept. Under deadline pressure, tests are the first things cut. TDD's strength is that tests are written when the behavior is fresh in your mind and before the pressure mounts. The later you wait, the harder (and more costly) testing becomes.

Summary: The Rhythm of Red-Green-Refactor

The Red-Green-Refactor cycle is the fundamental heartbeat of Test-Driven Development. Let's consolidate the key lessons:

Key Takeaways

•Red means specification — Writing a failing test defines what you're about to build. The test is a contract.
•Green means functionality — Make it work by any means necessary. Simple, hardcoded, ugly—doesn't matter yet.
•Refactor means design — With passing tests as a safety net, improve structure without changing behavior.
•Keep cycles short — 30 seconds to 5 minutes. Long cycles lose TDD's localization benefits.
•Trust the process — Design emerges from many small cycles. Don't over-engineer upfront.
•Never skip phases — Each phase serves a purpose. Skipping any undermines the whole.

What's Next:

Now that you understand the mechanics of the TDD cycle, we'll explore why this discipline produces better designs. The next page examines TDD's benefits for design quality—how testing first forces decoupled, focused, and naturally modular code.

Page Complete

You now understand the Red-Green-Refactor cycle that forms the core rhythm of TDD. This isn't just a testing technique—it's a design discipline that produces better software through thousands of small, verified steps. Next, we'll see how this cycle directly improves the design quality of your code.