System Design (LLD)Why Testing Matters for LLD

Why Testing Matters for Low-Level Design

LevelIntermediate

Duration60 mins

TopicWhy Testing Matters for LLD

4 / 4

TDD and Design Quality

Designing Through Tests

There's a radical idea in software development: write the test before the code. This practice, known as Test-Driven Development (TDD), seems backwards at first. How can you test something that doesn't exist?

But this apparent contradiction is precisely the point. By writing the test first, you're forced to think about what the code should do before you think about how it should work. You design the interface before the implementation. You specify the behavior before the mechanism.

TDD isn't just about catching bugs earlier—it's about designing better software. The discipline of test-first development creates natural pressure toward well-designed, loosely-coupled, highly-cohesive code. Developers who practice TDD consistently report that their designs improve, not just their test coverage.

This page explores how TDD influences design quality, the mechanics of the practice, the cognitive shift required, and when and how to apply TDD for maximum design benefit.

What You Will Learn

By the end of this page, you will understand the TDD cycle and its design implications, how writing tests first shapes code structure, the emergent design benefits of TDD, when TDD is most valuable, and common challenges and how to overcome them.

The TDD Cycle: Red, Green, Refactor

TDD follows a simple, repetitive cycle. Understanding this cycle is essential before exploring its design implications.

The Three Phases:

1. RED — Write a Failing Test

Write a test for behavior that doesn't exist yet
Run the test — it should fail (red)
The failure confirms the test is valid

2. GREEN — Make the Test Pass

Write the minimum code to make the test pass
Don't optimize, don't generalize, just pass the test
Run the test — it should pass (green)

3. REFACTOR — Improve the Code

Now improve the implementation
Remove duplication, improve names, clarify structure
Run tests after each change to confirm behavior preserved
When satisfied, return to RED with the next behavior

TDDCycleExample.java
Java
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
// TDD Cycle Example: Building a Stack
 
// --- CYCLE 1 ---
 
// RED: Write failing test
@Test
void newStack_isEmpty() {
    Stack<Integer> stack = new Stack<>();
    assertTrue(stack.isEmpty());
}
// Test fails: Stack class doesn't exist!
 
// GREEN: Minimal code to pass
class Stack<T> {
    boolean isEmpty() { return true; }
}
// Test passes!
 
// REFACTOR: Nothing to refactor yet
 
// --- CYCLE 2 ---
 
// RED: New failing test
@Test
void push_makesStackNonEmpty() {
    Stack<Integer> stack = new Stack<>();
    stack.push(1);
    assertFalse(stack.isEmpty());
}
// Test fails: push doesn't exist!
 
// GREEN: Minimal code to pass
class Stack<T> {
    private boolean hasElements = false;
    
    void push(T item) { hasElements = true; }
    boolean isEmpty() { return !hasElements; }
}
// Test passes!
 
// --- CYCLE 3 ---
 
// RED: New failing test
@Test
void pop_returnsLastPushedItem() {
    Stack<Integer> stack = new Stack<>();
    stack.push(42);
    assertEquals(42, stack.pop());
}
// Test fails: pop doesn't return pushed value!
 
// GREEN: Minimal code to pass
class Stack<T> {
    private T lastItem;
    
    void push(T item) { lastItem = item; }
    T pop() { return lastItem; }
    boolean isEmpty() { return lastItem == null; }
}
// Test passes!
 
// REFACTOR: This is getting messy. Need a proper data structure.
class Stack<T> {
    private List<T> items = new ArrayList<>();
    
    void push(T item) { items.add(item); }
    T pop() { return items.remove(items.size() - 1); }
    boolean isEmpty() { return items.isEmpty(); }
}
// All tests still pass! Behavior preserved, structure improved.

Why This Cycle Works:

Each phase serves a distinct purpose:

Phase	Purpose	Design Benefit
RED	Define what the code should do	Forces you to design the interface first
GREEN	Prove the test can pass	Ensures testability from the start
REFACTOR	Improve without changing behavior	Separates "make it work" from "make it right"

The cycle creates a rhythm: specify, implement, improve, repeat. This rhythm fights the common tendency to over-engineer (trying to anticipate all future needs) or under-engineer (shipping messy code with promises to clean up later).

The Key Insight:

By writing the test first, you become the first user of your own API. You experience the awkwardness of bad design before you've built it. You can fix interfaces cheaply, while they're still just ideas in tests.

The Meaning of 'Minimum'

In the GREEN phase, 'minimum code' really means minimum. If you can pass the test by returning a constant, do that. If you can pass by adding one if statement, do that. This might feel silly, but it forces you to write more tests to specify more behavior. Each test adds a constraint that shapes the final design.

How TDD Shapes Design

TDD creates natural pressure toward good design. The constraints of test-first development make certain design problems immediately painful, forcing you to solve them early.

Design Pressures TDD Creates:

TDD Design Pressures

•Pressure toward dependency injection — To test a class, you need to control its dependencies. TDD forces you to pass in dependencies rather than hard-code them.
•Pressure toward small classes — Classes with many responsibilities are hard to test. TDD naturally pushes toward single-responsibility designs.
•Pressure toward clear interfaces — You design the interface before implementation. Awkward interfaces become obvious when you try to use them in tests.
•Pressure toward loose coupling — Tightly coupled classes require extensive setup. TDD developers quickly learn to prefer loose coupling.
•Pressure toward testable behavior — If a behavior is hard to test, you refactor to make it testable—which usually means making it better designed.

Example: TDD Forcing Dependency Injection

Consider building a NotificationService. Without TDD, you might write:

NotificationService.java
Java
1
2
3
4
5
6
7
8
9
10
11
// WITHOUT TDD: Hidden dependencies
public class NotificationService {
    public void notifyUser(String userId, String message) {
        // Internally creates its own dependencies
        SmtpEmailSender emailer = new SmtpEmailSender("smtp.company.com");
        UserDatabase db = new PostgresUserDatabase("prod-connection");
        
        User user = db.findById(userId);
        emailer.send(user.getEmail(), message);
    }
}

Now try to write a test first with TDD:

NotificationServiceTest.java
Java
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
// TDD forces you to think about the interface first
 
@Test
void notifyUser_sendsEmailToUser() {
    // How do I test this without sending real emails?
    // How do I test this without a real database?
    
    // I need to control the dependencies!
    // The design must change to allow this.
    
    // Solution: Inject dependencies
    UserRepository mockRepo = mock(UserRepository.class);
    EmailSender mockEmail = mock(EmailSender.class);
    
    when(mockRepo.findById("user-123"))
        .thenReturn(new User("user-123", "alice@example.com"));
    
    NotificationService service = new NotificationService(mockRepo, mockEmail);
    
    service.notifyUser("user-123", "Hello!");
    
    verify(mockEmail).send("alice@example.com", "Hello!");
}
 
// WITH TDD: The design is forced to be testable
public class NotificationService {
    private final UserRepository userRepository;
    private final EmailSender emailSender;
    
    // Dependencies are injected - testable!
    public NotificationService(UserRepository userRepository, 
                                EmailSender emailSender) {
        this.userRepository = userRepository;
        this.emailSender = emailSender;
    }
    
    public void notifyUser(String userId, String message) {
        User user = userRepository.findById(userId);
        emailSender.send(user.getEmail(), message);
    }
}

The pattern is clear: TDD made the dependency injection necessary. The original design was untestable; TDD couldn't proceed without fixing it. The better design emerged from the constraint of testability.

Design by Constraint

TDD works by adding constraints. Each test is a constraint that the implementation must satisfy. Constraints limit options, which paradoxically leads to better designs. When anything is possible, bad designs are likely. When tests constrain the design, bad designs become impractical.

Emergent Design: Letting Structure Evolve

One of TDD's most powerful aspects is emergent design—the idea that good design can evolve incrementally through the TDD cycle, rather than being specified upfront.

Traditional Design Approach:

Analyze requirements completely
Design comprehensive class hierarchies
Specify all interfaces and relationships
Implementation follows design

Emergent Design in TDD:

Write a test for the simplest case
Implement the minimum solution
Write the next test
Refactor when patterns emerge
Design evolves from accumulated tests

The key difference: In traditional design, you predict what you'll need. In emergent design, you discover what you need.

Why Emergent Design Often Beats Upfront Design:

Factor	Upfront Design	Emergent Design
Information availability	Must decide with incomplete info	Decides as info emerges
Prediction accuracy	Often wrong about future needs	Responds to actual needs
Wasted effort	Features designed but never needed	Only builds what's tested
Flexibility	Locked into early decisions	Adapts through refactoring
Complexity	Often over-engineered	Grows only as needed

Example: Watching Design Emerge

Let's see emergent design in action. Suppose we're building a simple shopping cart. We start with the simplest test:

ShoppingCartEvolution.java
Java
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
// STEP 1: Simplest possible test
@Test void newCart_hasZeroTotal() {
    Cart cart = new Cart();
    assertEquals(Money.ZERO, cart.getTotal());
}
 
// Simplest implementation:
class Cart {
    Money getTotal() { return Money.ZERO; }
}
 
// STEP 2: Add an item
@Test void cart_withOneItem_hasTotalOfItemPrice() {
    Cart cart = new Cart();
    cart.addItem(new Item("Widget", Money.of(10)));
    assertEquals(Money.of(10), cart.getTotal());
}
 
// Implementation grows:
class Cart {
    private Money total = Money.ZERO;
    
    void addItem(Item item) { 
        total = total.add(item.getPrice()); 
    }
    
    Money getTotal() { return total; }
}
 
// STEP 3: Multiple items
@Test void cart_withMultipleItems_hasSumOfPrices() {
    Cart cart = new Cart();
    cart.addItem(new Item("Widget", Money.of(10)));
    cart.addItem(new Item("Gadget", Money.of(15)));
    assertEquals(Money.of(25), cart.getTotal());
}
// Implementation already handles this! Tests pass.
 
// STEP 4: Remove item
@Test void removeItem_subtractsFromTotal() {
    Cart cart = new Cart();
    Item widget = new Item("Widget", Money.of(10));
    cart.addItem(widget);
    cart.removeItem(widget);
    assertEquals(Money.ZERO, cart.getTotal());
}
 
// Need to track items now:
class Cart {
    private List<Item> items = new ArrayList<>();
    
    void addItem(Item item) { items.add(item); }
    void removeItem(Item item) { items.remove(item); }
    
    Money getTotal() {
        return items.stream()
            .map(Item::getPrice)
            .reduce(Money.ZERO, Money::add);
    }
}
// Design *emerged* from needing to remove items!
 
// STEP 5: Apply discount
@Test void applyDiscount_reducesTotal() {
    Cart cart = new Cart();
    cart.addItem(new Item("Widget", Money.of(100)));
    cart.applyDiscount(Discount.percentage(10));
    assertEquals(Money.of(90), cart.getTotal());
}
 
// Discount concept emerges:
class Cart {
    private List<Item> items = new ArrayList<>();
    private Discount discount = Discount.NONE;
    
    void applyDiscount(Discount discount) { 
        this.discount = discount; 
    }
    
    Money getTotal() {
        Money subtotal = items.stream()
            .map(Item::getPrice)
            .reduce(Money.ZERO, Money::add);
        return discount.applyTo(subtotal);
    }
}

Notice how the design evolved:

Started with just a total (no items stored)
Added items, still just tracked total
Needed removal → design changed to store items
Needed discounts → discount concept introduced

At no point did we predict the final structure. The structure emerged from the requirements, revealed through tests. This avoids over-engineering while ensuring every feature is tested.

The YAGNI Principle

YAGNI = "You Aren't Gonna Need It." TDD naturally enforces YAGNI, because you only build what you have tests for. Without a test requiring a feature, the feature doesn't get built. This eliminates the waste of speculative design.

TDD and the SOLID Principles

TDD creates natural pressure toward SOLID principles. This isn't coincidental—the SOLID principles describe what makes code testable, and TDD demands testability.

How TDD Enforces Each SOLID Principle:

TDD's Pressure Toward SOLID
Principle	TDD Pressure	What Happens Without It
Single Responsibility	Classes with multiple responsibilities require tests for all responsibilities, making test files bloated and setup complex	You feel the pain in test setup and maintenance
Open/Closed	To add extension tests without modifying existing ones, you need extension points	Adding features breaks existing tests
Liskov Substitution	Tests written for base types should pass for subtypes; violations cause test failures	Subtype tests fail unexpectedly
Interface Segregation	Fat interfaces require mocking methods you don't use; tests become noisy	Mock setup becomes excessive
Dependency Inversion	Without abstraction, you can't substitute test doubles; tests become integration tests	Tests are slow and non-deterministic

Deep Dive: TDD and the Single Responsibility Principle

Let's examine how TDD pushes toward SRP through discomfort:

SRPEvolution.java
Java
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
// TDD reveals SRP violations through testing pain
 
// ATTEMPT 1: Testing a class that does too much
// "OrderProcessor" that validates, charges, and emails
 
class OrderProcessorTest {
    private PaymentGateway mockPayment;
    private EmailService mockEmail;
    private InventoryService mockInventory;
    private FraudDetector mockFraud;
    private TaxCalculator mockTax;
    private ShippingCalculator mockShipping;
    // ... 6 mocks just to test processing
    
    @BeforeEach
    void setup() {
        mockPayment = mock(PaymentGateway.class);
        mockEmail = mock(EmailService.class);
        mockInventory = mock(InventoryService.class);
        mockFraud = mock(FraudDetector.class);
        mockTax = mock(TaxCalculator.class);
        mockShipping = mock(ShippingCalculator.class);
        
        // Default behaviors for all mocks
        when(mockFraud.isFraudulent(any())).thenReturn(false);
        when(mockInventory.checkAvailability(any())).thenReturn(true);
        when(mockPayment.charge(any())).thenReturn(new PaymentResult(...));
        // ... more setup
    }
    
    @Test
    void processOrder_happy_path() {
        // Finally, the actual test - buried under 30 lines of setup
    }
}
 
// THE PAIN TELLS US: This class has too many responsibilities!
 
// REFACTORED with SRP - each class is easy to test:
 
class OrderValidatorTest {
    @Test
    void validate_withValidOrder_returnsValid() {
        OrderValidator validator = new OrderValidator();
        Order order = validOrder();
        
        ValidationResult result = validator.validate(order);
        
        assertTrue(result.isValid());
    }
    // Simple: tests one thing, no mocks needed
}
 
class PaymentProcessorTest {
    @Test
    void processPayment_withSufficientFunds_succeeds() {
        PaymentGateway mockGateway = mock(PaymentGateway.class);
        when(mockGateway.charge(any())).thenReturn(PaymentResult.success());
        
        PaymentProcessor processor = new PaymentProcessor(mockGateway);
        
        PaymentResult result = processor.process(payment(100.00));
        
        assertTrue(result.isSuccessful());
    }
    // Simple: one responsibility, one mock
}
 
// The "pain" of testing pushed us toward better design!

The Mock Count Heuristic

When a test requires more than 3 mocks, it's usually a sign that the class under test has too many dependencies—likely an SRP violation. TDD practitioners learn to recognize this signal and refactor before the problem grows.

The Cognitive Benefits of TDD

Beyond structural improvements, TDD changes how developers think about problems. These cognitive shifts lead to better designs.

Cognitive Shifts in TDD:

Without TDD

•Think about HOW to implement
•Focus on algorithms and data structures
•Build features, then figure out how to test
•API emerges from implementation convenience
•Edge cases considered as afterthoughts
•Testing is burden at the end

With TDD

•Think about WHAT to achieve
•Focus on behaviors and outcomes
•Design usage, then implement
•API designed for the consumer (test)
•Edge cases are first-class tests
•Testing is design exploration

The Client Perspective

When you write a test first, you're acting as a client of your own code. This forces you to experience your API from the user's perspective before it exists.

Compare:

Without TDD: You build an implementation and expose whatever methods are convenient for the internals.

With TDD: You design calls that make sense for the caller, then figure out how to implement them.

This client-first perspective catches awkward APIs before they're built. Questions emerge naturally:

Is this method name clear?
Are these parameters intuitive?
Is this the right level of abstraction?
Will future callers understand this interface?

Reduced Cognitive Load

TDD also reduces the cognitive load of implementation:

Focus on one behavior at a time — Each test cycle handles one small concern
Clear success criteria — The test defines when you're done
Permission to be pragmatic — "Make it pass" allows simple solutions
Deferred optimization — Clean up in refactoring, not during implementation
Safety net for experimentation — Tests catch mistakes during refactoring

The TDD Mindfulness

TDD forces you to slow down and think deliberately about what you're building. In a world of copy-paste programming and StackOverflow answers, this deliberate thinking produces better designs than reactive coding.

When TDD Works Best (and When It Doesn't)

TDD is a powerful tool, but like all tools, it works better in some contexts than others. Understanding when TDD shines helps you apply it effectively.

TDD Works Excellently For:

Excellent TDD Contexts

•Business logic — Complex rules benefit from explicit test specifications
•API design — Tests force you to think about the consumer experience
•Algorithmic code — Edge cases and correctness are critical
•New features — Clean slate allows test-first approach
•Bug fixes — Reproduce bug in test, then fix it (guaranteed regression prevention)
•Library/framework code — Code that will be reused needs solid contracts
•Domain models — Core entities that embody business concepts

TDD Is Less Effective For:

Challenging TDD Contexts

•Exploratory coding — When you don't know what you're building yet, spiking without tests can be valuable. Write tests after you understand the problem.
•UI layout and aesthetics — Visual design is better evaluated visually. Test behavior, not appearance.
•Third-party integration — When you don't control the external system, testing is complex. Integration tests may be more pragmatic.
•Performance optimization — Profiling guides optimization better than tests. Add performance assertions after finding bottlenecks.
•Highly concurrent code — Race conditions are hard to test deterministically. Other techniques (thread-safety analysis, model checking) may be needed.
•Legacy code without tests — Retrofitting TDD is hard. Start with characterization tests to stabilize before TDD.

The Spike-and-Stabilize Pattern

For exploratory work, consider this pattern:

Spike: Write code without tests to explore the problem space
Learn: Understand what you actually need
Discard: Throw away the spike (yes, really)
TDD: Rebuild with test-first discipline, informed by what you learned

This combines exploration benefits with TDD's design benefits. The spike was never meant to be production code—it was a learning exercise.

Don't Force TDD Where It Hurts

Dogmatic TDD—insisting on test-first for every line of code—can be counterproductive. The goal is good software. If another approach produces better results in a specific context, use it. TDD is a tool, not a religion.

Overcoming Common TDD Challenges

TDD has a learning curve. New practitioners face common challenges that, once understood, become surmountable obstacles.

Challenge 1: "I don't know what test to write first"

This is the starting problem—looking at requirements and feeling paralyzed about where to begin.

Solution: Start with the simplest possible case. The zero case, the empty case, the null case. For a calculator: test that 0 + 0 = 0. For a list: test that a new list is empty. These trivial tests get you moving, and the next test becomes clearer.

Challenge 2: "My tests are too slow"

Slow tests break the TDD rhythm. If you can't run tests every minute, feedback is too slow.

Solution: This usually indicates tests are hitting I/O, databases, or external services. Move toward more unit tests and fewer integration tests. Use mocks/stubs for slow dependencies. Run only affected tests during development.

Challenge 3: "I end up writing the implementation in my head while writing the test"

Sometimes you know the implementation, and thinking about what to test feels redundant.

Solution: This is normal and okay. The test still provides value even if you can see the implementation. Focus on what the behavior should be, not how you'll implement it. The implementation might change; the behavior specification remains valuable.

Challenge 4: "My tests are brittle and break on every change"

Tests break even when the actual behavior is unchanged.

Solution: You're testing implementation details instead of behavior. Refocus tests on observables: inputs, outputs, and side effects. Avoid asserting on internal state. Test "what" not "how."

Challenge 5: "TDD feels too slow"

The upfront effort of writing tests feels like it slows development.

Solution: Measure total time, including debugging and bug fixes. TDD typically slows initial coding by 15-35% but reduces debugging time by 50-90%. Net result is often faster delivery, especially for complex features. The slowdown is an investment that pays back quickly.

Challenge 6: "I can't figure out how to test this code"

Some code seems inherently untestable.

Solution: Untestable code is usually poorly designed code. TDD's entire point is that testability drives you toward better design. If the code is hard to test, the design needs to change. Extract dependencies, introduce interfaces, break up responsibilities.

Common TDD Challenges and Solutions
Challenge	Root Cause	Solution
What test first?	Analysis paralysis	Start with simplest case
Tests too slow	I/O in tests	More mocks, fewer integration tests
Mental implementation	Normal cognition	Focus on behavior, not mechanism
Brittle tests	Testing implementation	Test inputs/outputs, not internals
Feels slow	Incorrect time accounting	Measure total time including debug
Untestable code	Poor design	Let testability guide design changes

The Three-Month Point

TDD proficiency typically takes about 3 months of consistent practice. The first month feels awkward and slow. The second month shows improvement. By the third month, TDD becomes natural and the design benefits become obvious. Push through the initial discomfort.

Summary: TDD as Design Discipline

We've explored how Test-Driven Development influences and improves design quality. Let's consolidate the key insights:

Key Takeaways

•Red-Green-Refactor — The TDD cycle separates specification (test), implementation (code), and improvement (refactor) into distinct phases.
•TDD forces good design — Testability requirements create pressure toward dependency injection, small classes, and clear interfaces.
•Emergent design — Structure evolves from tests rather than being predicted upfront. This avoids over-engineering.
•SOLID alignment — TDD naturally pushes toward SOLID principles because violations make testing painful.
•Cognitive shift — TDD changes thinking from 'how to implement' to 'what to achieve', leading to cleaner APIs.
•Context matters — TDD excels for business logic, APIs, and algorithms; less so for exploratory coding or UI aesthetics.
•Challenges are surmountable — Common TDD obstacles have known solutions. Persist through the learning curve.

Module Complete: Why Testing Matters for LLD

We've now covered the four pillars of why testing matters for Low-Level Design:

Testing as Design Feedback — Tests reveal design problems through testability friction
Testing for Confidence — Tests enable bold action through verified correctness
Testing and Maintainability — Tests preserve knowledge and enable safe evolution
TDD and Design Quality — Test-first development naturally produces better designs

The next module will explore the practical fundamentals of unit testing, putting these principles into practice.

Module Complete

You now understand why testing is fundamental to Low-Level Design. Testing isn't an afterthought—it's woven into the fabric of good design. Whether through design feedback, confidence building, maintainability support, or TDD discipline, testing shapes the code you write and the systems you build.

4 / 4

Loading learning content...

System Design (LLD)Why Testing Matters for LLD

Why Testing Matters for Low-Level Design

LevelIntermediate

Duration60 mins

TopicWhy Testing Matters for LLD

4 / 4

TDD and Design Quality

Designing Through Tests

This page explores how TDD influences design quality, the mechanics of the practice, the cognitive shift required, and when and how to apply TDD for maximum design benefit.

What You Will Learn

The TDD Cycle: Red, Green, Refactor

TDD follows a simple, repetitive cycle. Understanding this cycle is essential before exploring its design implications.

The Three Phases:

1. RED — Write a Failing Test

Write a test for behavior that doesn't exist yet
Run the test — it should fail (red)
The failure confirms the test is valid

2. GREEN — Make the Test Pass

Write the minimum code to make the test pass
Don't optimize, don't generalize, just pass the test
Run the test — it should pass (green)

3. REFACTOR — Improve the Code

Now improve the implementation
Remove duplication, improve names, clarify structure
Run tests after each change to confirm behavior preserved
When satisfied, return to RED with the next behavior

TDDCycleExample.java
Java
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
// TDD Cycle Example: Building a Stack
 
// --- CYCLE 1 ---
 
// RED: Write failing test
@Test
void newStack_isEmpty() {
    Stack<Integer> stack = new Stack<>();
    assertTrue(stack.isEmpty());
}
// Test fails: Stack class doesn't exist!
 
// GREEN: Minimal code to pass
class Stack<T> {
    boolean isEmpty() { return true; }
}
// Test passes!
 
// REFACTOR: Nothing to refactor yet
 
// --- CYCLE 2 ---
 
// RED: New failing test
@Test
void push_makesStackNonEmpty() {
    Stack<Integer> stack = new Stack<>();
    stack.push(1);
    assertFalse(stack.isEmpty());
}
// Test fails: push doesn't exist!
 
// GREEN: Minimal code to pass
class Stack<T> {
    private boolean hasElements = false;
    
    void push(T item) { hasElements = true; }
    boolean isEmpty() { return !hasElements; }
}
// Test passes!
 
// --- CYCLE 3 ---
 
// RED: New failing test
@Test
void pop_returnsLastPushedItem() {
    Stack<Integer> stack = new Stack<>();
    stack.push(42);
    assertEquals(42, stack.pop());
}
// Test fails: pop doesn't return pushed value!
 
// GREEN: Minimal code to pass
class Stack<T> {
    private T lastItem;
    
    void push(T item) { lastItem = item; }
    T pop() { return lastItem; }
    boolean isEmpty() { return lastItem == null; }
}
// Test passes!
 
// REFACTOR: This is getting messy. Need a proper data structure.
class Stack<T> {
    private List<T> items = new ArrayList<>();
    
    void push(T item) { items.add(item); }
    T pop() { return items.remove(items.size() - 1); }
    boolean isEmpty() { return items.isEmpty(); }
}
// All tests still pass! Behavior preserved, structure improved.

Why This Cycle Works:

Each phase serves a distinct purpose:

Phase	Purpose	Design Benefit
RED	Define what the code should do	Forces you to design the interface first
GREEN	Prove the test can pass	Ensures testability from the start
REFACTOR	Improve without changing behavior	Separates "make it work" from "make it right"

The Key Insight:

The Meaning of 'Minimum'

How TDD Shapes Design

TDD creates natural pressure toward good design. The constraints of test-first development make certain design problems immediately painful, forcing you to solve them early.

Design Pressures TDD Creates:

TDD Design Pressures

•Pressure toward dependency injection — To test a class, you need to control its dependencies. TDD forces you to pass in dependencies rather than hard-code them.
•Pressure toward small classes — Classes with many responsibilities are hard to test. TDD naturally pushes toward single-responsibility designs.
•Pressure toward clear interfaces — You design the interface before implementation. Awkward interfaces become obvious when you try to use them in tests.
•Pressure toward loose coupling — Tightly coupled classes require extensive setup. TDD developers quickly learn to prefer loose coupling.
•Pressure toward testable behavior — If a behavior is hard to test, you refactor to make it testable—which usually means making it better designed.

Example: TDD Forcing Dependency Injection

Consider building a NotificationService. Without TDD, you might write:

NotificationService.java
Java
1
2
3
4
5
6
7
8
9
10
11
// WITHOUT TDD: Hidden dependencies
public class NotificationService {
    public void notifyUser(String userId, String message) {
        // Internally creates its own dependencies
        SmtpEmailSender emailer = new SmtpEmailSender("smtp.company.com");
        UserDatabase db = new PostgresUserDatabase("prod-connection");
        
        User user = db.findById(userId);
        emailer.send(user.getEmail(), message);
    }
}

Now try to write a test first with TDD:

NotificationServiceTest.java
Java
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
// TDD forces you to think about the interface first
 
@Test
void notifyUser_sendsEmailToUser() {
    // How do I test this without sending real emails?
    // How do I test this without a real database?
    
    // I need to control the dependencies!
    // The design must change to allow this.
    
    // Solution: Inject dependencies
    UserRepository mockRepo = mock(UserRepository.class);
    EmailSender mockEmail = mock(EmailSender.class);
    
    when(mockRepo.findById("user-123"))
        .thenReturn(new User("user-123", "alice@example.com"));
    
    NotificationService service = new NotificationService(mockRepo, mockEmail);
    
    service.notifyUser("user-123", "Hello!");
    
    verify(mockEmail).send("alice@example.com", "Hello!");
}
 
// WITH TDD: The design is forced to be testable
public class NotificationService {
    private final UserRepository userRepository;
    private final EmailSender emailSender;
    
    // Dependencies are injected - testable!
    public NotificationService(UserRepository userRepository, 
                                EmailSender emailSender) {
        this.userRepository = userRepository;
        this.emailSender = emailSender;
    }
    
    public void notifyUser(String userId, String message) {
        User user = userRepository.findById(userId);
        emailSender.send(user.getEmail(), message);
    }
}

Design by Constraint

Emergent Design: Letting Structure Evolve

One of TDD's most powerful aspects is emergent design—the idea that good design can evolve incrementally through the TDD cycle, rather than being specified upfront.

Traditional Design Approach:

Analyze requirements completely
Design comprehensive class hierarchies
Specify all interfaces and relationships
Implementation follows design

Emergent Design in TDD:

Write a test for the simplest case
Implement the minimum solution
Write the next test
Refactor when patterns emerge
Design evolves from accumulated tests

The key difference: In traditional design, you predict what you'll need. In emergent design, you discover what you need.

Why Emergent Design Often Beats Upfront Design:

Factor	Upfront Design	Emergent Design
Information availability	Must decide with incomplete info	Decides as info emerges
Prediction accuracy	Often wrong about future needs	Responds to actual needs
Wasted effort	Features designed but never needed	Only builds what's tested
Flexibility	Locked into early decisions	Adapts through refactoring
Complexity	Often over-engineered	Grows only as needed

Example: Watching Design Emerge

Let's see emergent design in action. Suppose we're building a simple shopping cart. We start with the simplest test:

ShoppingCartEvolution.java
Java
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
// STEP 1: Simplest possible test
@Test void newCart_hasZeroTotal() {
    Cart cart = new Cart();
    assertEquals(Money.ZERO, cart.getTotal());
}
 
// Simplest implementation:
class Cart {
    Money getTotal() { return Money.ZERO; }
}
 
// STEP 2: Add an item
@Test void cart_withOneItem_hasTotalOfItemPrice() {
    Cart cart = new Cart();
    cart.addItem(new Item("Widget", Money.of(10)));
    assertEquals(Money.of(10), cart.getTotal());
}
 
// Implementation grows:
class Cart {
    private Money total = Money.ZERO;
    
    void addItem(Item item) { 
        total = total.add(item.getPrice()); 
    }
    
    Money getTotal() { return total; }
}
 
// STEP 3: Multiple items
@Test void cart_withMultipleItems_hasSumOfPrices() {
    Cart cart = new Cart();
    cart.addItem(new Item("Widget", Money.of(10)));
    cart.addItem(new Item("Gadget", Money.of(15)));
    assertEquals(Money.of(25), cart.getTotal());
}
// Implementation already handles this! Tests pass.
 
// STEP 4: Remove item
@Test void removeItem_subtractsFromTotal() {
    Cart cart = new Cart();
    Item widget = new Item("Widget", Money.of(10));
    cart.addItem(widget);
    cart.removeItem(widget);
    assertEquals(Money.ZERO, cart.getTotal());
}
 
// Need to track items now:
class Cart {
    private List<Item> items = new ArrayList<>();
    
    void addItem(Item item) { items.add(item); }
    void removeItem(Item item) { items.remove(item); }
    
    Money getTotal() {
        return items.stream()
            .map(Item::getPrice)
            .reduce(Money.ZERO, Money::add);
    }
}
// Design *emerged* from needing to remove items!
 
// STEP 5: Apply discount
@Test void applyDiscount_reducesTotal() {
    Cart cart = new Cart();
    cart.addItem(new Item("Widget", Money.of(100)));
    cart.applyDiscount(Discount.percentage(10));
    assertEquals(Money.of(90), cart.getTotal());
}
 
// Discount concept emerges:
class Cart {
    private List<Item> items = new ArrayList<>();
    private Discount discount = Discount.NONE;
    
    void applyDiscount(Discount discount) { 
        this.discount = discount; 
    }
    
    Money getTotal() {
        Money subtotal = items.stream()
            .map(Item::getPrice)
            .reduce(Money.ZERO, Money::add);
        return discount.applyTo(subtotal);
    }
}

Notice how the design evolved:

Started with just a total (no items stored)
Added items, still just tracked total
Needed removal → design changed to store items
Needed discounts → discount concept introduced

At no point did we predict the final structure. The structure emerged from the requirements, revealed through tests. This avoids over-engineering while ensuring every feature is tested.

The YAGNI Principle

TDD and the SOLID Principles

TDD creates natural pressure toward SOLID principles. This isn't coincidental—the SOLID principles describe what makes code testable, and TDD demands testability.

How TDD Enforces Each SOLID Principle:

TDD's Pressure Toward SOLID
Principle	TDD Pressure	What Happens Without It
Single Responsibility	Classes with multiple responsibilities require tests for all responsibilities, making test files bloated and setup complex	You feel the pain in test setup and maintenance
Open/Closed	To add extension tests without modifying existing ones, you need extension points	Adding features breaks existing tests
Liskov Substitution	Tests written for base types should pass for subtypes; violations cause test failures	Subtype tests fail unexpectedly
Interface Segregation	Fat interfaces require mocking methods you don't use; tests become noisy	Mock setup becomes excessive
Dependency Inversion	Without abstraction, you can't substitute test doubles; tests become integration tests	Tests are slow and non-deterministic

Deep Dive: TDD and the Single Responsibility Principle

Let's examine how TDD pushes toward SRP through discomfort:

SRPEvolution.java
Java
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
// TDD reveals SRP violations through testing pain
 
// ATTEMPT 1: Testing a class that does too much
// "OrderProcessor" that validates, charges, and emails
 
class OrderProcessorTest {
    private PaymentGateway mockPayment;
    private EmailService mockEmail;
    private InventoryService mockInventory;
    private FraudDetector mockFraud;
    private TaxCalculator mockTax;
    private ShippingCalculator mockShipping;
    // ... 6 mocks just to test processing
    
    @BeforeEach
    void setup() {
        mockPayment = mock(PaymentGateway.class);
        mockEmail = mock(EmailService.class);
        mockInventory = mock(InventoryService.class);
        mockFraud = mock(FraudDetector.class);
        mockTax = mock(TaxCalculator.class);
        mockShipping = mock(ShippingCalculator.class);
        
        // Default behaviors for all mocks
        when(mockFraud.isFraudulent(any())).thenReturn(false);
        when(mockInventory.checkAvailability(any())).thenReturn(true);
        when(mockPayment.charge(any())).thenReturn(new PaymentResult(...));
        // ... more setup
    }
    
    @Test
    void processOrder_happy_path() {
        // Finally, the actual test - buried under 30 lines of setup
    }
}
 
// THE PAIN TELLS US: This class has too many responsibilities!
 
// REFACTORED with SRP - each class is easy to test:
 
class OrderValidatorTest {
    @Test
    void validate_withValidOrder_returnsValid() {
        OrderValidator validator = new OrderValidator();
        Order order = validOrder();
        
        ValidationResult result = validator.validate(order);
        
        assertTrue(result.isValid());
    }
    // Simple: tests one thing, no mocks needed
}
 
class PaymentProcessorTest {
    @Test
    void processPayment_withSufficientFunds_succeeds() {
        PaymentGateway mockGateway = mock(PaymentGateway.class);
        when(mockGateway.charge(any())).thenReturn(PaymentResult.success());
        
        PaymentProcessor processor = new PaymentProcessor(mockGateway);
        
        PaymentResult result = processor.process(payment(100.00));
        
        assertTrue(result.isSuccessful());
    }
    // Simple: one responsibility, one mock
}
 
// The "pain" of testing pushed us toward better design!

The Mock Count Heuristic

The Cognitive Benefits of TDD

Beyond structural improvements, TDD changes how developers think about problems. These cognitive shifts lead to better designs.

Cognitive Shifts in TDD:

Without TDD

•Think about HOW to implement
•Focus on algorithms and data structures
•Build features, then figure out how to test
•API emerges from implementation convenience
•Edge cases considered as afterthoughts
•Testing is burden at the end

With TDD

•Think about WHAT to achieve
•Focus on behaviors and outcomes
•Design usage, then implement
•API designed for the consumer (test)
•Edge cases are first-class tests
•Testing is design exploration

The Client Perspective

When you write a test first, you're acting as a client of your own code. This forces you to experience your API from the user's perspective before it exists.

Compare:

Without TDD: You build an implementation and expose whatever methods are convenient for the internals.

With TDD: You design calls that make sense for the caller, then figure out how to implement them.

This client-first perspective catches awkward APIs before they're built. Questions emerge naturally:

Is this method name clear?
Are these parameters intuitive?
Is this the right level of abstraction?
Will future callers understand this interface?

Reduced Cognitive Load

TDD also reduces the cognitive load of implementation:

Focus on one behavior at a time — Each test cycle handles one small concern
Clear success criteria — The test defines when you're done
Permission to be pragmatic — "Make it pass" allows simple solutions
Deferred optimization — Clean up in refactoring, not during implementation
Safety net for experimentation — Tests catch mistakes during refactoring

The TDD Mindfulness

When TDD Works Best (and When It Doesn't)

TDD is a powerful tool, but like all tools, it works better in some contexts than others. Understanding when TDD shines helps you apply it effectively.

TDD Works Excellently For:

Excellent TDD Contexts

•Business logic — Complex rules benefit from explicit test specifications
•API design — Tests force you to think about the consumer experience
•Algorithmic code — Edge cases and correctness are critical
•New features — Clean slate allows test-first approach
•Bug fixes — Reproduce bug in test, then fix it (guaranteed regression prevention)
•Library/framework code — Code that will be reused needs solid contracts
•Domain models — Core entities that embody business concepts

TDD Is Less Effective For:

Challenging TDD Contexts

•Exploratory coding — When you don't know what you're building yet, spiking without tests can be valuable. Write tests after you understand the problem.
•UI layout and aesthetics — Visual design is better evaluated visually. Test behavior, not appearance.
•Third-party integration — When you don't control the external system, testing is complex. Integration tests may be more pragmatic.
•Performance optimization — Profiling guides optimization better than tests. Add performance assertions after finding bottlenecks.
•Highly concurrent code — Race conditions are hard to test deterministically. Other techniques (thread-safety analysis, model checking) may be needed.
•Legacy code without tests — Retrofitting TDD is hard. Start with characterization tests to stabilize before TDD.

The Spike-and-Stabilize Pattern

For exploratory work, consider this pattern:

Spike: Write code without tests to explore the problem space
Learn: Understand what you actually need
Discard: Throw away the spike (yes, really)
TDD: Rebuild with test-first discipline, informed by what you learned

This combines exploration benefits with TDD's design benefits. The spike was never meant to be production code—it was a learning exercise.

Don't Force TDD Where It Hurts

Overcoming Common TDD Challenges

TDD has a learning curve. New practitioners face common challenges that, once understood, become surmountable obstacles.

Challenge 1: "I don't know what test to write first"

This is the starting problem—looking at requirements and feeling paralyzed about where to begin.

Challenge 2: "My tests are too slow"

Slow tests break the TDD rhythm. If you can't run tests every minute, feedback is too slow.

Challenge 3: "I end up writing the implementation in my head while writing the test"

Sometimes you know the implementation, and thinking about what to test feels redundant.

Challenge 4: "My tests are brittle and break on every change"

Tests break even when the actual behavior is unchanged.

Solution: You're testing implementation details instead of behavior. Refocus tests on observables: inputs, outputs, and side effects. Avoid asserting on internal state. Test "what" not "how."

Challenge 5: "TDD feels too slow"

The upfront effort of writing tests feels like it slows development.

Challenge 6: "I can't figure out how to test this code"

Some code seems inherently untestable.

Common TDD Challenges and Solutions
Challenge	Root Cause	Solution
What test first?	Analysis paralysis	Start with simplest case
Tests too slow	I/O in tests	More mocks, fewer integration tests
Mental implementation	Normal cognition	Focus on behavior, not mechanism
Brittle tests	Testing implementation	Test inputs/outputs, not internals
Feels slow	Incorrect time accounting	Measure total time including debug
Untestable code	Poor design	Let testability guide design changes

The Three-Month Point

Summary: TDD as Design Discipline

We've explored how Test-Driven Development influences and improves design quality. Let's consolidate the key insights:

Key Takeaways

•Red-Green-Refactor — The TDD cycle separates specification (test), implementation (code), and improvement (refactor) into distinct phases.
•TDD forces good design — Testability requirements create pressure toward dependency injection, small classes, and clear interfaces.
•Emergent design — Structure evolves from tests rather than being predicted upfront. This avoids over-engineering.
•SOLID alignment — TDD naturally pushes toward SOLID principles because violations make testing painful.
•Cognitive shift — TDD changes thinking from 'how to implement' to 'what to achieve', leading to cleaner APIs.
•Context matters — TDD excels for business logic, APIs, and algorithms; less so for exploratory coding or UI aesthetics.
•Challenges are surmountable — Common TDD obstacles have known solutions. Persist through the learning curve.

Module Complete: Why Testing Matters for LLD

We've now covered the four pillars of why testing matters for Low-Level Design:

Testing as Design Feedback — Tests reveal design problems through testability friction
Testing for Confidence — Tests enable bold action through verified correctness
Testing and Maintainability — Tests preserve knowledge and enable safe evolution
TDD and Design Quality — Test-first development naturally produces better designs

The next module will explore the practical fundamentals of unit testing, putting these principles into practice.

Module Complete

4 / 4