Testing Internals - Learning Module

Loading content...

0/246

Design for Testability

Building Testability In from the Start

The best solution to testing private methods isn't any of the techniques we've discussed—it's designing code that doesn't need those techniques.

Design for Testability is the discipline of writing code that is naturally and easily testable without compromising encapsulation. It's not about making things public, using reflection, or other workarounds. It's about structural choices that make testability a natural consequence of good design.

Remarkably, the design principles that maximize testability are the same principles that produce clean, maintainable, flexible code. Testability isn't an add-on concern—it's a quality indicator. Code that's hard to test is code that has design problems. Code that's easy to test is code that follows good design principles.

This page explores the architectural patterns and design principles that make testability effortless.

What You Will Learn

By the end of this page, you will understand how to design classes that are inherently testable. You'll learn the principles of dependency injection, interface segregation, single responsibility, and separation of concerns—not as abstract concepts, but as practical tools that make testing private methods a non-issue.

Testability as Design Feedback

Before diving into specific techniques, let's establish a fundamental insight: difficulty testing is a design smell.

When you struggle to test a class, the class is telling you something:

Hard to instantiate? → Too many dependencies or hidden dependencies
Need to call many methods before testing? → Complex setup indicates poor cohesion
Private methods feel like they need tests? → Responsibilities may be misplaced
Can't verify outcomes without checking internal state? → Missing observable behaviors
Tests are verbose and repetitive? → The class may be doing too much

Instead of fighting to test bad design, listen to the feedback and improve the design. Tests become easy naturally.

Design Smells Revealed by Testing Difficulty

•Constructor does too much — If setup is complex, the constructor is doing work that doesn't belong there
•Static method calls — Dependencies on static methods can't be substituted for testing
•God class — Too many responsibilities make focused tests impossible
•Tight coupling — Dependencies on concrete classes instead of interfaces prevent substitution
•Hidden dependencies — Using new inside methods hides dependencies that can't be mocked
•Side effects everywhere — Methods that read files, make network calls, or modify global state
•Temporal coupling — Methods must be called in specific order, requiring complex test choreography

The Testing Litmus Test

Ask: 'Can I test this class in complete isolation, with only in-memory test data, in under one second?' If no: the design needs work. This isn't about test speed—it's about coupling, dependencies, and complexity. A well-designed class with reasonable scope can always be tested quickly in isolation.

Dependency Injection: The Foundation of Testability

Dependency Injection (DI) is the single most important pattern for testability. The principle is simple: instead of creating dependencies internally, receive them from outside.

This simple shift has profound testability implications:

Dependencies can be replaced with test doubles
No hidden dependencies that surprise tests
Clear declaration of what a class needs
Easy to configure different behaviors for different test scenarios

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
// ❌ BEFORE: Hidden dependencies - hard to test
class OrderService {
    private emailService: EmailService;
    private paymentGateway: PaymentGateway;
    private inventoryRepository: InventoryRepository;
    
    constructor() {
        // Hidden dependencies created internally
        this.emailService = new SmtpEmailService();
        this.paymentGateway = new StripePaymentGateway();
        this.inventoryRepository = new PostgresInventoryRepository();
    }
    
    public async processOrder(order: Order): Promise<OrderResult> {
        // Uses real email, real payments, real database
        // Testing requires actual infrastructure!
    }
}
 
// Testing this requires:
// - A real SMTP server (or email goes out!)
// - A real Stripe account (or payments fail!)
// - A real Postgres database (or queries fail!)
// Effectively UNTESTABLE in isolation
 
// ✅ AFTER: Injected dependencies - easy to test
class OrderService {
    constructor(
        private readonly emailService: EmailService,
        private readonly paymentGateway: PaymentGateway,
        private readonly inventoryRepository: InventoryRepository
    ) {}
    
    public async processOrder(order: Order): Promise<OrderResult> {
        // Validate the order
        if (order.items.length === 0) {
            throw new EmptyOrderError('Order must contain items');
        }
        
        // Process payment
        const paymentResult = await this.paymentGateway.charge(
            order.customerId,
            order.total
        );
        if (!paymentResult.success) {
            throw new PaymentFailedError(paymentResult.error);
        }
        
        // Reserve inventory
        await this.inventoryRepository.reserve(order.items);
        
        // Send confirmation
        await this.emailService.sendOrderConfirmation(order);
        
        return { orderId: order.id, status: 'CONFIRMED' };
    }
}
 
// Testing is now trivial
describe('OrderService', () => {
    let service: OrderService;
    let mockEmailService: MockEmailService;
    let mockPaymentGateway: MockPaymentGateway;
    let mockInventoryRepository: MockInventoryRepository;
    
    beforeEach(() => {
        mockEmailService = new MockEmailService();
        mockPaymentGateway = new MockPaymentGateway();
        mockInventoryRepository = new MockInventoryRepository();
        
        service = new OrderService(
            mockEmailService,
            mockPaymentGateway,
            mockInventoryRepository
        );
    });
    
    test('rejects empty orders', async () => {
        const emptyOrder = { items: [], total: Money.ZERO };
        
        await expect(service.processOrder(emptyOrder))
            .rejects.toThrow(EmptyOrderError);
    });
    
    test('processes payment before reserving inventory', async () => {
        const order = createValidOrder();
        
        await service.processOrder(order);
        
        // Verify order of operations
        const callOrder = [
            ...mockPaymentGateway.callLog,
            ...mockInventoryRepository.callLog
        ].sort((a, b) => a.timestamp - b.timestamp);
        
        expect(callOrder[0].method).toBe('charge');
        expect(callOrder[1].method).toBe('reserve');
    });
    
    test('does not send email if payment fails', async () => {
        mockPaymentGateway.simulateFailure('Insufficient funds');
        const order = createValidOrder();
        
        await expect(service.processOrder(order))
            .rejects.toThrow(PaymentFailedError);
        
        expect(mockEmailService.sendOrderConfirmation).not.toHaveBeenCalled();
    });
});

Dependency Injection Best Practices

•Inject through constructor — Makes dependencies explicit and required
•Inject interfaces, not implementations — Allows any conforming implementation in tests
•Keep constructors simple — Just assign parameters to fields; don't do work
•Avoid optional dependencies — Default implementations hide behavior; inject everything
•Use a DI container in production — Let the container wire dependencies; tests wire manually

Interface Segregation: Narrow Dependencies

Dependency injection works best when dependencies are narrow and focused. Interface Segregation means depending on small, specific interfaces rather than large, general ones.

For testability, narrow interfaces mean simpler mocks. If your class depends on an interface with 20 methods but only uses 2, you have to implement 18 unused methods in your mock. Narrow interfaces mean small, focused mocks.

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
// ❌ BEFORE: Fat interface makes testing verbose
interface UserRepository {
    findById(id: string): Promise<User | null>;
    findByEmail(email: string): Promise<User | null>;
    findAll(): Promise<User[]>;
    findByRole(role: string): Promise<User[]>;
    save(user: User): Promise<void>;
    update(user: User): Promise<void>;
    delete(id: string): Promise<void>;
    updatePassword(id: string, password: string): Promise<void>;
    updateEmail(id: string, email: string): Promise<void>;
    countByRole(role: string): Promise<number>;
    existsByEmail(email: string): Promise<boolean>;
    findActiveUsers(): Promise<User[]>;
    deactivate(id: string): Promise<void>;
    // ... 15 more methods ...
}
 
class PasswordResetService {
    constructor(private readonly userRepository: UserRepository) {}
    
    public async resetPassword(email: string): Promise<void> {
        // Only uses findByEmail and updatePassword
        const user = await this.userRepository.findByEmail(email);
        if (!user) throw new UserNotFoundError();
        
        const newPassword = generateSecureToken();
        await this.userRepository.updatePassword(user.id, newPassword);
        // send email...
    }
}
 
// Testing requires implementing ALL 20+ methods even though we use only 2
const mockUserRepository: UserRepository = {
    findById: jest.fn(),
    findByEmail: jest.fn(),
    findAll: jest.fn(),
    findByRole: jest.fn(),
    save: jest.fn(),
    update: jest.fn(),
    delete: jest.fn(),
    updatePassword: jest.fn(),
    updateEmail: jest.fn(),
    countByRole: jest.fn(),
    existsByEmail: jest.fn(),
    findActiveUsers: jest.fn(),
    deactivate: jest.fn(),
    // ... tedious ...
};
 
// ✅ AFTER: Segregated interfaces mean focused mocks
interface UserFinder {
    findByEmail(email: string): Promise<User | null>;
}
 
interface PasswordUpdater {
    updatePassword(id: string, password: string): Promise<void>;
}
 
class PasswordResetService {
    constructor(
        private readonly userFinder: UserFinder,
        private readonly passwordUpdater: PasswordUpdater
    ) {}
    
    public async resetPassword(email: string): Promise<void> {
        const user = await this.userFinder.findByEmail(email);
        if (!user) throw new UserNotFoundError();
        
        const newPassword = generateSecureToken();
        await this.passwordUpdater.updatePassword(user.id, newPassword);
    }
}
 
// Testing is minimal and focused
describe('PasswordResetService', () => {
    test('updates password for existing user', async () => {
        // Only need to mock what we use
        const mockFinder: UserFinder = {
            findByEmail: jest.fn().mockResolvedValue({ id: '123', email: 'test@example.com' })
        };
        const mockUpdater: PasswordUpdater = {
            updatePassword: jest.fn().mockResolvedValue(undefined)
        };
        
        const service = new PasswordResetService(mockFinder, mockUpdater);
        
        await service.resetPassword('test@example.com');
        
        expect(mockUpdater.updatePassword).toHaveBeenCalledWith(
            '123',
            expect.any(String)
        );
    });
    
    test('throws for non-existent user', async () => {
        const mockFinder: UserFinder = {
            findByEmail: jest.fn().mockResolvedValue(null)
        };
        const mockUpdater: PasswordUpdater = {
            updatePassword: jest.fn()
        };
        
        const service = new PasswordResetService(mockFinder, mockUpdater);
        
        await expect(service.resetPassword('unknown@example.com'))
            .rejects.toThrow(UserNotFoundError);
        
        expect(mockUpdater.updatePassword).not.toHaveBeenCalled();
    });
});

Role Interfaces

Notice how the segregated interfaces describe roles: 'UserFinder' and 'PasswordUpdater'. These role-based interfaces can be implemented by different classes or combined in one class. The production UserRepository can implement both, while tests provide minimal implementations. This is the Interface Segregation Principle applied for testability.

Single Responsibility: Small Classes Are Testable Classes

The Single Responsibility Principle (SRP) states that a class should have only one reason to change. For testability, this means: small, focused classes are easier to test than large, multipurpose classes.

When a class does one thing, testing that one thing is straightforward. When it does ten things, testing becomes a combinatorial explosion of scenarios.

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
156
157
158
159
160
161
162
// ❌ BEFORE: Class with multiple responsibilities
class UserManager {
    constructor(
        private readonly db: Database,
        private readonly emailService: EmailService,
        private readonly paymentService: PaymentService,
        private readonly auditLog: AuditLog
    ) {}
    
    // Authentication responsibility
    public async login(email: string, password: string): Promise<Session> {
        const user = await this.db.findUserByEmail(email);
        if (!user || !this.verifyPassword(password, user.passwordHash)) {
            await this.auditLog.recordFailedLogin(email);
            throw new AuthenticationError();
        }
        const session = this.createSession(user);
        await this.auditLog.recordSuccessfulLogin(user.id);
        return session;
    }
    
    // Registration responsibility
    public async register(data: RegistrationData): Promise<User> {
        const hashedPassword = await this.hashPassword(data.password);
        const user = await this.db.createUser({ ...data, passwordHash: hashedPassword });
        await this.emailService.sendWelcomeEmail(user);
        await this.auditLog.recordRegistration(user.id);
        return user;
    }
    
    // Subscription responsibility  
    public async subscribe(userId: string, plan: Plan): Promise<Subscription> {
        const user = await this.db.findUserById(userId);
        const payment = await this.paymentService.createSubscription(user, plan);
        const subscription = await this.db.createSubscription(userId, plan, payment.id);
        await this.emailService.sendSubscriptionConfirmation(user, plan);
        await this.auditLog.recordSubscription(userId, plan.id);
        return subscription;
    }
    
    // Profile responsibility
    public async updateProfile(userId: string, data: ProfileData): Promise<User> {
        const user = await this.db.updateUser(userId, data);
        await this.auditLog.recordProfileUpdate(userId);
        return user;
    }
    
    // Password management responsibility
    public async changePassword(userId: string, oldPass: string, newPass: string): Promise<void> {
        // More complex logic...
    }
    
    // 10 more methods covering billing, notifications, etc.
    
    private verifyPassword(input: string, hash: string): boolean { /* ... */ }
    private hashPassword(password: string): Promise<string> { /* ... */ }
    private createSession(user: User): Session { /* ... */ }
}
 
// Testing this God class requires:
// - Mocking 4+ dependencies for every test
// - Understanding which methods interact with which dependencies
// - Complex setup for each test scenario
// - Risk of tests becoming interdependent
 
// ✅ AFTER: Separate classes for each responsibility
class AuthenticationService {
    constructor(
        private readonly userFinder: UserFinder,
        private readonly passwordVerifier: PasswordVerifier,
        private readonly sessionManager: SessionManager,
        private readonly auditLog: AuthAuditLog
    ) {}
    
    public async login(email: string, password: string): Promise<Session> {
        const user = await this.userFinder.findByEmail(email);
        
        if (!user || !await this.passwordVerifier.verify(password, user.passwordHash)) {
            await this.auditLog.recordFailedLogin(email);
            throw new AuthenticationError('Invalid credentials');
        }
        
        const session = await this.sessionManager.createSession(user);
        await this.auditLog.recordSuccessfulLogin(user.id);
        
        return session;
    }
}
 
class RegistrationService {
    constructor(
        private readonly userCreator: UserCreator,
        private readonly passwordHasher: PasswordHasher,
        private readonly welcomeMailer: WelcomeMailer
    ) {}
    
    public async register(data: RegistrationData): Promise<User> {
        const hashedPassword = await this.passwordHasher.hash(data.password);
        const user = await this.userCreator.create({ ...data, passwordHash: hashedPassword });
        await this.welcomeMailer.send(user);
        return user;
    }
}
 
class SubscriptionService {
    constructor(
        private readonly paymentProcessor: PaymentProcessor,
        private readonly subscriptionRepository: SubscriptionRepository,
        private readonly confirmationMailer: SubscriptionConfirmationMailer
    ) {}
    
    public async subscribe(user: User, plan: Plan): Promise<Subscription> {
        const payment = await this.paymentProcessor.createSubscription(user, plan);
        const subscription = await this.subscriptionRepository.create(user.id, plan, payment.id);
        await this.confirmationMailer.send(user, plan);
        return subscription;
    }
}
 
// Now each class is focused and testable
describe('AuthenticationService', () => {
    let service: AuthenticationService;
    let mockUserFinder: UserFinder;
    let mockPasswordVerifier: PasswordVerifier;
    let mockSessionManager: SessionManager;
    let mockAuditLog: AuthAuditLog;
    
    beforeEach(() => {
        mockUserFinder = createMock<UserFinder>();
        mockPasswordVerifier = createMock<PasswordVerifier>();
        mockSessionManager = createMock<SessionManager>();
        mockAuditLog = createMock<AuthAuditLog>();
        
        service = new AuthenticationService(
            mockUserFinder,
            mockPasswordVerifier,
            mockSessionManager,
            mockAuditLog
        );
    });
    
    test('returns session for valid credentials', async () => {
        const user = createUser({ passwordHash: 'hash123' });
        mockUserFinder.findByEmail.mockResolvedValue(user);
        mockPasswordVerifier.verify.mockResolvedValue(true);
        mockSessionManager.createSession.mockResolvedValue(createSession());
        
        const session = await service.login('test@example.com', 'password123');
        
        expect(session).toBeDefined();
        expect(mockAuditLog.recordSuccessfulLogin).toHaveBeenCalledWith(user.id);
    });
    
    test('throws for unknown user', async () => {
        mockUserFinder.findByEmail.mockResolvedValue(null);
        
        await expect(service.login('unknown@example.com', 'password'))
            .rejects.toThrow(AuthenticationError);
        
        expect(mockAuditLog.recordFailedLogin).toHaveBeenCalledWith('unknown@example.com');
    });
});

The Class Size Heuristic

If your class has more than 5-7 dependencies, or more than 10-15 public methods, it probably violates SRP. Consider splitting it. If tests for a class regularly require mocking many dependencies, that's a sign the class does too much.

Separating Pure Logic from Side Effects

One of the most powerful testability patterns is separating pure computation from side effects. Pure functions (no side effects, output depends only on input) are trivially testable. Side effects (I/O, database, network) require mocking.

By extracting pure logic into separate functions or classes, you make the core business logic testable without any mocking, while the I/O coordination becomes a thin, easily mocked layer.

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
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
// ❌ BEFORE: Logic and I/O intertwined
class InvoiceService {
    constructor(
        private readonly db: Database,
        private readonly taxService: ExternalTaxApi,
        private readonly pdfGenerator: PdfGenerator,
        private readonly emailService: EmailService
    ) {}
    
    public async generateAndSendInvoice(orderId: string): Promise<void> {
        // Fetch order from database
        const order = await this.db.findOrder(orderId);
        if (!order) throw new OrderNotFoundError();
        
        // Calculate line items (pure logic buried here)
        let subtotal = 0;
        const lineItems = order.items.map(item => {
            const lineTotal = item.unitPrice * item.quantity;
            if (item.quantity >= 10) {
                // Bulk discount
                lineTotal *= 0.9;
            }
            subtotal += lineTotal;
            return { ...item, lineTotal };
        });
        
        // Fetch tax rate (external API)
        const taxRate = await this.taxService.getRateForAddress(order.shippingAddress);
        
        // Calculate totals (pure logic)
        const taxAmount = subtotal * taxRate;
        const total = subtotal + taxAmount;
        
        // Apply any credits (pure logic)
        const adjustedTotal = Math.max(0, total - (order.credits || 0));
        
        // Generate PDF (side effect)
        const pdf = await this.pdfGenerator.generate({
            lineItems,
            subtotal,
            taxRate,
            taxAmount,
            total,
            adjustedTotal
        });
        
        // Send email (side effect)
        await this.emailService.sendInvoice(order.customerEmail, pdf);
        
        // Save record (side effect)
        await this.db.saveInvoice({
            orderId,
            lineItems,
            subtotal,
            taxAmount,
            total: adjustedTotal,
            sentAt: new Date()
        });
    }
}
 
// Testing requires mocking 4 dependencies, even to test simple calculation logic
 
// ✅ AFTER: Separated pure logic from side effects
 
// Pure domain logic - no dependencies, trivially testable
class InvoiceCalculator {
    public calculateLineItem(item: OrderItem): LineItemResult {
        let lineTotal = item.unitPrice * item.quantity;
        
        // Bulk discount for 10+ items
        if (item.quantity >= 10) {
            lineTotal *= 0.9;
        }
        
        return {
            description: item.description,
            quantity: item.quantity,
            unitPrice: item.unitPrice,
            discount: item.quantity >= 10 ? 0.1 : 0,
            lineTotal
        };
    }
    
    public calculateSubtotal(lineItems: LineItemResult[]): number {
        return lineItems.reduce((sum, item) => sum + item.lineTotal, 0);
    }
    
    public calculateTax(subtotal: number, taxRate: number): number {
        return subtotal * taxRate;
    }
    
    public calculateTotal(subtotal: number, tax: number, credits: number): number {
        return Math.max(0, subtotal + tax - credits);
    }
    
    public buildInvoice(
        order: Order,
        lineItems: LineItemResult[],
        taxRate: number
    ): InvoiceData {
        const subtotal = this.calculateSubtotal(lineItems);
        const taxAmount = this.calculateTax(subtotal, taxRate);
        const total = this.calculateTotal(subtotal, taxAmount, order.credits || 0);
        
        return {
            orderId: order.id,
            lineItems,
            subtotal,
            taxRate,
            taxAmount,
            total,
            credits: order.credits || 0
        };
    }
}
 
// I/O coordination layer - thin, mocks are simple
class InvoiceService {
    constructor(
        private readonly orderRepository: OrderRepository,
        private readonly taxService: TaxService,
        private readonly calculator: InvoiceCalculator,
        private readonly pdfGenerator: PdfGenerator,
        private readonly invoiceSender: InvoiceSender,
        private readonly invoiceRepository: InvoiceRepository
    ) {}
    
    public async generateAndSendInvoice(orderId: string): Promise<void> {
        // Fetch
        const order = await this.orderRepository.findById(orderId);
        if (!order) throw new OrderNotFoundError();
        
        // Calculate (delegates to pure logic)
        const lineItems = order.items.map(item => this.calculator.calculateLineItem(item));
        const taxRate = await this.taxService.getRateForAddress(order.shippingAddress);
        const invoiceData = this.calculator.buildInvoice(order, lineItems, taxRate);
        
        // Side effects
        const pdf = await this.pdfGenerator.generate(invoiceData);
        await this.invoiceSender.send(order.customerEmail, pdf);
        await this.invoiceRepository.save({ ...invoiceData, sentAt: new Date() });
    }
}
 
// Pure logic is exhaustively testable with no mocks
describe('InvoiceCalculator', () => {
    const calculator = new InvoiceCalculator();
    
    describe('calculateLineItem', () => {
        test('calculates line total without discount', () => {
            const item = { unitPrice: 10, quantity: 5, description: 'Widget' };
            
            const result = calculator.calculateLineItem(item);
            
            expect(result.lineTotal).toBe(50);
            expect(result.discount).toBe(0);
        });
        
        test('applies 10% bulk discount for 10+ items', () => {
            const item = { unitPrice: 10, quantity: 10, description: 'Widget' };
            
            const result = calculator.calculateLineItem(item);
            
            expect(result.lineTotal).toBe(90);  // 100 * 0.9
            expect(result.discount).toBe(0.1);
        });
        
        test('applies 10% bulk discount for large quantities', () => {
            const item = { unitPrice: 100, quantity: 50, description: 'Widget' };
            
            const result = calculator.calculateLineItem(item);
            
            expect(result.lineTotal).toBe(4500);  // 5000 * 0.9
        });
    });
    
    describe('calculateTotal', () => {
        test('combines subtotal and tax minus credits', () => {
            const result = calculator.calculateTotal(100, 8, 20);
            
            expect(result).toBe(88);  // 100 + 8 - 20
        });
        
        test('never returns negative', () => {
            const result = calculator.calculateTotal(50, 4, 100);
            
            expect(result).toBe(0);  // Max(0, 50 + 4 - 100)
        });
    });
});

The Functional Core, Imperative Shell Pattern

This pattern is sometimes called 'Functional Core, Imperative Shell'. The core contains pure business logic that's trivially testable. The shell handles I/O, coordinates the core, and is lightly tested (or tested with integration tests). Most testing effort focuses on the pure core, where it's easy and valuable.

Designing for Observable Behavior

Well-designed classes expose their behavior through observable outputs rather than requiring inspection of internal state. If you can only verify a class works by checking private fields, the design is missing something.

Observable behaviors include:

Return values from methods
Exceptions thrown
Side effects on injected dependencies (verifiable via mocks)
State accessible through public getters
Events emitted

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
// ❌ BEFORE: Behavior only visible through internal state
class ShoppingCart {
    private items: CartItem[] = [];
    private appliedCoupons: string[] = [];
    private discount: number = 0;
    
    public addItem(product: Product, quantity: number): void {
        const existing = this.items.find(i => i.product.id === product.id);
        if (existing) {
            existing.quantity += quantity;
        } else {
            this.items.push({ product, quantity });
        }
        // Discount is recalculated internally
        this.recalculateDiscount();
    }
    
    public applyCoupon(code: string): void {
        this.appliedCoupons.push(code);
        this.recalculateDiscount();
    }
    
    private recalculateDiscount(): void {
        // Complex discount logic
        this.discount = /* calculated value */;
    }
}
 
// To test, we'd need to peek at private fields
test('discount is applied when adding 10+ items', () => {
    const cart = new ShoppingCart();
    cart.addItem(product, 10);
    
    // ❌ How do we verify discount was applied?
    // Option 1: Reflection to check this.discount
    // Option 2: Hope there's a getDiscount() we forgot to show
    // Both are problematic
});
 
// ✅ AFTER: Rich observable behavior
class ShoppingCart {
    private items: CartItem[] = [];
    private appliedCoupons: string[] = [];
    
    public addItem(product: Product, quantity: number): CartUpdateResult {
        const existing = this.items.find(i => i.product.id === product.id);
        if (existing) {
            existing.quantity += quantity;
        } else {
            this.items.push({ product, quantity });
        }
        
        return this.createUpdateResult();
    }
    
    public applyCoupon(code: string): CouponResult {
        if (!this.isValidCoupon(code)) {
            return { success: false, error: 'Invalid coupon' };
        }
        
        this.appliedCoupons.push(code);
        return { 
            success: true, 
            discountApplied: this.calculateCouponDiscount(code),
            newTotal: this.getTotal() 
        };
    }
    
    // Observable: computed from internal state
    public getSubtotal(): Money {
        return this.items.reduce(
            (sum, item) => sum.plus(item.product.price.times(item.quantity)),
            Money.ZERO
        );
    }
    
    // Observable: discount amount
    public getDiscount(): Money {
        return this.calculateTotalDiscount();
    }
    
    // Observable: final total
    public getTotal(): Money {
        return this.getSubtotal().minus(this.getDiscount());
    }
    
    // Observable: list of items (immutable copy)
    public getItems(): ReadonlyArray<CartItem> {
        return [...this.items];
    }
    
    // Observable: cart summary for UI
    public getSummary(): CartSummary {
        return {
            itemCount: this.items.reduce((count, item) => count + item.quantity, 0),
            uniqueProducts: this.items.length,
            subtotal: this.getSubtotal(),
            discount: this.getDiscount(),
            total: this.getTotal(),
            appliedCoupons: [...this.appliedCoupons]
        };
    }
    
    private createUpdateResult(): CartUpdateResult {
        return {
            itemCount: this.items.reduce((c, i) => c + i.quantity, 0),
            subtotal: this.getSubtotal(),
            discount: this.getDiscount(),
            total: this.getTotal()
        };
    }
    
    private calculateTotalDiscount(): Money { /* ... */ }
    private calculateCouponDiscount(code: string): Money { /* ... */ }
    private isValidCoupon(code: string): boolean { /* ... */ }
}
 
// Testing through observable behavior
describe('ShoppingCart discounts', () => {
    test('bulk discount appears in total when adding 10+ items', () => {
        const cart = new ShoppingCart();
        const product = { id: '1', price: Money.of(10) };
        
        const result = cart.addItem(product, 10);
        
        // Observable: discount is reflected in total
        expect(result.subtotal).toEqual(Money.of(100));
        expect(result.discount.greaterThan(Money.ZERO)).toBe(true);
        expect(result.total.lessThan(result.subtotal)).toBe(true);
    });
    
    test('applying valid coupon returns applied discount', () => {
        const cart = new ShoppingCart();
        cart.addItem(product, 5);
        
        const result = cart.applyCoupon('SAVE10');
        
        // Observable: coupon application result
        expect(result.success).toBe(true);
        expect(result.discountApplied).toEqual(Money.of(5)); // 10% of $50
    });
    
    test('cart summary reflects all applied coupons', () => {
        const cart = new ShoppingCart();
        cart.addItem(product, 5);
        cart.applyCoupon('SAVE10');
        cart.applyCoupon('EXTRA5');
        
        const summary = cart.getSummary();
        
        // Observable: full cart state
        expect(summary.appliedCoupons).toEqual(['SAVE10', 'EXTRA5']);
        expect(summary.discount.greaterThan(Money.ZERO)).toBe(true);
    });
});

The Observation Test

For every important behavior your class has, ask: 'How can a client observe this behavior?' If the answer requires peeking at private fields, add a public getter, return value, or event. The class should make its behaviors visible to clients and tests alike.

Avoiding Hidden Dependencies

Hidden dependencies are anything your class needs that isn't visible in its constructor signature. They create testing nightmares because tests can't control or substitute them.

Common Hidden Dependencies and Fixes
Hidden Dependency	Testing Problem	Solution
Static method calls	Can't substitute with test implementation	Wrap in interface, inject instance
new inside methods	Can't control created objects	Inject factory or instance
Global/singleton access	Shared state across tests	Inject dependency explicitly
System.currentTimeMillis()	Time-dependent behavior untestable	Inject Clock interface
Random number generation	Non-deterministic tests	Inject RandomGenerator interface
Environment variables	Test environment variation	Inject Configuration object
File system access	Tests need real files	Inject FileSystem abstraction

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
// ❌ BEFORE: Hidden dependencies everywhere
class AuditLogger {
    public log(action: string, userId: string): void {
        // Hidden: current time from system
        const timestamp = new Date();
        
        // Hidden: random ID generation
        const logId = Math.random().toString(36).substring(7);
        
        // Hidden: environment variable
        const environment = process.env.NODE_ENV || 'development';
        
        // Hidden: file system access
        const logPath = `/var/log/audit-${timestamp.toISOString().split('T')[0]}.log`;
        require('fs').appendFileSync(logPath, JSON.stringify({
            logId,
            timestamp,
            environment,
            action,
            userId
        }) + '\n');
    }
}
 
// Testing this is nearly impossible:
// - Time changes between runs
// - Random IDs are unpredictable
// - NODE_ENV varies by environment
// - Writes to actual file system
 
// ✅ AFTER: All dependencies explicit
interface Clock {
    now(): Date;
}
 
interface IdGenerator {
    generate(): string;
}
 
interface Configuration {
    environment: string;
}
 
interface LogWriter {
    write(path: string, content: string): void;
}
 
class AuditLogger {
    constructor(
        private readonly clock: Clock,
        private readonly idGenerator: IdGenerator,
        private readonly config: Configuration,
        private readonly logWriter: LogWriter
    ) {}
    
    public log(action: string, userId: string): void {
        const timestamp = this.clock.now();
        const logId = this.idGenerator.generate();
        
        const logEntry = {
            logId,
            timestamp: timestamp.toISOString(),
            environment: this.config.environment,
            action,
            userId
        };
        
        const logPath = `/var/log/audit-${timestamp.toISOString().split('T')[0]}.log`;
        this.logWriter.write(logPath, JSON.stringify(logEntry) + '\n');
    }
}
 
// Now testing is deterministic
describe('AuditLogger', () => {
    let logger: AuditLogger;
    let mockClock: Clock;
    let mockIdGenerator: IdGenerator;
    let mockLogWriter: LogWriter;
    
    beforeEach(() => {
        mockClock = { now: jest.fn().mockReturnValue(new Date('2024-01-15T10:30:00Z')) };
        mockIdGenerator = { generate: jest.fn().mockReturnValue('test-id-123') };
        mockLogWriter = { write: jest.fn() };
        
        logger = new AuditLogger(
            mockClock,
            mockIdGenerator,
            { environment: 'test' },
            mockLogWriter
        );
    });
    
    test('writes log entry with correct timestamp', () => {
        logger.log('USER_LOGIN', 'user123');
        
        expect(mockLogWriter.write).toHaveBeenCalledWith(
            '/var/log/audit-2024-01-15.log',
            expect.stringContaining('"timestamp":"2024-01-15T10:30:00.000Z"')
        );
    });
    
    test('includes generated ID in log entry', () => {
        logger.log('USER_LOGIN', 'user123');
        
        expect(mockLogWriter.write).toHaveBeenCalledWith(
            expect.any(String),
            expect.stringContaining('"logId":"test-id-123"')
        );
    });
    
    test('includes environment from configuration', () => {
        logger.log('USER_LOGIN', 'user123');
        
        expect(mockLogWriter.write).toHaveBeenCalledWith(
            expect.any(String),
            expect.stringContaining('"environment":"test"')
        );
    });
});

Summary: The Testable Design Principles

Design for testability isn't about tricks or workarounds—it's about following design principles that naturally produce testable code. The same principles that create clean, maintainable, flexible software also create easily testable software.

Key Principles for Testable Design

•Inject dependencies — Don't create them internally. Receive all dependencies through the constructor.
•Depend on interfaces — Narrow, role-based interfaces are easier to mock than broad, concrete classes.
•Keep classes small and focused — Single responsibility means focused, simple tests.
•Separate pure logic from side effects — Pure logic needs no mocks; test it exhaustively.
•Design for observable behavior — Every important behavior should be visible through public getters, return values, or events.
•Eliminate hidden dependencies — Time, randomness, configuration, and I/O should all be injectable.
•Listen to test difficulty — Hard-to-test code is telling you the design needs work. Improve the design rather than fight the tests.

Module Complete:

Throughout this module, we've explored the nuanced world of testing private methods and internals:

Should we test private methods? — Usually no, but the answer depends on context
Testing through public interfaces — Techniques for comprehensive coverage without direct access
When to make methods testable — Pragmatic techniques when indirect testing isn't feasible
Design for testability — Principles that make testability a natural consequence of good design

The master insight is that testability concerns are design concerns in disguise. When testing is hard, the design needs improvement. When design is clean, testing is effortless. Private methods become a non-issue when classes are small, dependencies are injected, and behavior is observable.

Module Complete

You now have a comprehensive understanding of testing private methods and internals—from the philosophical debate to practical techniques to foundational design principles. Apply the judgment you've developed: prefer testing through public interfaces, use accessibility techniques sparingly when needed, and design for testability from the start. This approach produces both testable code and excellent design.