Mock Injection Through DIP - Dip And Testability | OneNoughtOne

0/246

Low-Level DesignDIP and Testability

DIP and Testability

LevelIntermediate

Duration60 mins

TopicDIP and Testability

1 / 4

Mock Injection Through DIP

The Testing Revelation

Software testing is one of the most critical disciplines in professional software development, yet many engineers struggle with a fundamental question: Why are some codebases easy to test while others seem virtually untestable? The answer lies not in testing frameworks or mocking libraries, but in a principle we've been studying: the Dependency Inversion Principle (DIP).

When you understand the deep connection between DIP and testability, you'll realize that testable code isn't an accident or a luxury—it's a natural consequence of principled design. Conversely, code that's hard to test is almost always code that violates DIP. This page explores the most immediate benefit of DIP compliance: the ability to inject mock dependencies, enabling true unit testing.

What You Will Learn

By the end of this page, you will understand how DIP enables mock injection, why direct dependencies make testing difficult, the mechanics of substituting test doubles through abstraction, and patterns for designing injectable dependencies that make testing seamless and natural.

The Problem of Direct Dependencies

Before we can appreciate how DIP enables mock injection, we must first understand what makes testing difficult in its absence. The root cause of untestable code is almost always direct dependencies—when a class creates or directly references concrete implementations rather than depending on abstractions.

Consider a seemingly simple class that processes payments:

DirectDependencyProblem
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
// ❌ UNTESTABLE: Direct dependencies make isolation impossible
class PaymentProcessor {
    private paymentGateway: StripeGateway;
    private logger: FileLogger;
    private auditService: DatabaseAuditService;
    
    constructor() {
        // Direct instantiation creates hard dependencies
        this.paymentGateway = new StripeGateway(
            process.env.STRIPE_API_KEY!
        );
        this.logger = new FileLogger('/var/log/payments.log');
        this.auditService = new DatabaseAuditService(
            new PostgresConnection(process.env.DB_URL!)
        );
    }
    
    async processPayment(amount: number, cardToken: string): Promise<PaymentResult> {
        this.logger.info(`Processing payment of ${amount}`);
        
        try {
            // Real Stripe API call - can't test without actual Stripe account
            const result = await this.paymentGateway.charge(amount, cardToken);
            
            // Real database write - can't test without database
            await this.auditService.recordTransaction(result);
            
            this.logger.info(`Payment successful: ${result.transactionId}`);
            return result;
        } catch (error) {
            this.logger.error(`Payment failed: ${error.message}`);
            throw error;
        }
    }
}

Attempting to test this code reveals multiple insurmountable problems:

Testing Roadblocks from Direct Dependencies

•External Service Coupling — Testing requires a real Stripe account with valid credentials. Each test costs real money, runs slowly due to network latency, and may fail due to external service issues completely unrelated to your code.
•Infrastructure Requirements — Tests need a real PostgreSQL database running and properly configured. This creates environment complexity, slows down test execution, and introduces flakiness from database state.
•File System Dependencies — The file logger writes to /var/log/payments.log. Tests either need write permissions to this location or will fail with permission errors—assuming the path even exists in the test environment.
•Environment Variables — Tests require specific environment variables to be set. Missing or incorrect values cause cryptic failures that have nothing to do with the logic being tested.
•State Pollution — Each test run leaves artifacts: files on disk, records in the database, possibly charges on the Stripe account. Tests affect each other and the external world unpredictably.
•Isolation Impossibility — You cannot test processPayment in isolation. Every test exercises the entire stack: Stripe API, database, file system—all intertwined with the business logic you're trying to verify.

The Fundamental Violation

This code violates DIP at its core: a high-level module (PaymentProcessor containing business logic) directly depends on low-level modules (StripeGateway, FileLogger, DatabaseAuditService—concrete implementations). The high-level module creates its own dependencies, making it impossible to substitute alternatives for testing.

Understanding Mock Injection

Mock injection is the technique of replacing real dependencies with test doubles (mocks, stubs, fakes) during testing. This allows you to:

Isolate the unit under test from external systems
Control the behavior of dependencies precisely
Verify interactions between the unit and its collaborators
Simulate edge cases that are difficult or impossible to reproduce with real systems

For mock injection to work, the code must be designed to accept dependencies from the outside rather than creating them internally. This is precisely what DIP enables.

Types of Test Doubles
Test Double	Purpose	Behavior	Use Case
Dummy	Fill parameter lists	Does nothing, may throw if called	When a dependency is required but not used in the specific test path
Stub	Provide canned answers	Returns pre-configured values	When you need to simulate specific responses from dependencies
Spy	Record interactions	Wraps real object, recording calls	When you need to verify interactions while using real behavior
Mock	Verify expectations	Pre-programmed with expected calls	When you need to verify specific methods were called with specific arguments
Fake	Working implementation	Simplified but functional alternative	When you need realistic behavior without external dependencies (e.g., in-memory database)

The critical insight: All these test doubles work by substituting for real dependencies. But substitution is only possible when the code under test depends on abstractions rather than concretions. This is DIP in action—the principle exists precisely to enable this kind of substitutability.

The DIP-Testing Connection

DIP isn't just an academic principle—it's the engineering prerequisite for testable design. When you follow DIP, mock injection becomes trivial. When you violate DIP, mock injection becomes impossible without reflection hacks or invasive testing frameworks that break encapsulation.

DIP-Enabled Testable Design

Let's transform the untestable PaymentProcessor into a properly designed, DIP-compliant version. The transformation requires three steps:

Define abstractions for each dependency
Accept dependencies through the constructor (dependency injection)
Program to interfaces, not implementations

Here's the refactored, testable version:

DIPCompliantDesign
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
// ✅ TESTABLE: DIP-compliant design with dependency injection
 
// Step 1: Define abstractions (interfaces)
interface PaymentGateway {
    charge(amount: number, cardToken: string): Promise<PaymentResult>;
}
 
interface Logger {
    info(message: string): void;
    error(message: string): void;
}
 
interface AuditService {
    recordTransaction(result: PaymentResult): Promise<void>;
}
 
// Step 2: Accept dependencies through constructor
// Step 3: Program to interfaces, not implementations
class PaymentProcessor {
    constructor(
        private readonly paymentGateway: PaymentGateway,  // Abstraction
        private readonly logger: Logger,                   // Abstraction
        private readonly auditService: AuditService        // Abstraction
    ) {}
    
    async processPayment(
        amount: number, 
        cardToken: string
    ): Promise<PaymentResult> {
        this.logger.info(`Processing payment of ${amount}`);
        
        try {
            const result = await this.paymentGateway.charge(amount, cardToken);
            await this.auditService.recordTransaction(result);
            
            this.logger.info(`Payment successful: ${result.transactionId}`);
            return result;
        } catch (error) {
            this.logger.error(`Payment failed: ${error.message}`);
            throw error;
        }
    }
}
 
// Production configuration (composition root)
const productionProcessor = new PaymentProcessor(
    new StripeGateway(process.env.STRIPE_API_KEY!),
    new FileLogger('/var/log/payments.log'),
    new DatabaseAuditService(new PostgresConnection(process.env.DB_URL!))
);

Critical observations about this design:

DIP Compliance Characteristics

•Abstractions are owned by the high-level module — The PaymentGateway, Logger, and AuditService interfaces are defined based on what PaymentProcessor needs, not based on what Stripe or PostgreSQL provides.
•No knowledge of concrete implementations — PaymentProcessor has no imports or references to StripeGateway, FileLogger, or DatabaseAuditService. It only knows about abstractions.
•Dependencies flow inward — StripeGateway implements PaymentGateway (depends on the abstraction). The high-level module doesn't depend on the low-level module; the low-level module depends on abstractions defined by the high-level module.
•Construction is separated from use — PaymentProcessor uses its dependencies but doesn't create them. Creation happens in a 'composition root' that wires everything together.

Implementing Mock Injection

With the DIP-compliant design, mock injection becomes trivial. We can create test doubles that implement the same interfaces and inject them into PaymentProcessor. Here are complete, production-quality test examples:

MockInjectionTests
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
// ✅ Complete test suite with mock injection
import { describe, it, expect, vi, beforeEach } from 'vitest';
 
// Mock implementations for testing
class MockPaymentGateway implements PaymentGateway {
    private chargeResult: PaymentResult | null = null;
    private shouldFail: boolean = false;
    private failureError: Error | null = null;
    
    // Configuration methods for test setup
    setChargeResult(result: PaymentResult): void {
        this.chargeResult = result;
    }
    
    setFailure(error: Error): void {
        this.shouldFail = true;
        this.failureError = error;
    }
    
    async charge(amount: number, cardToken: string): Promise<PaymentResult> {
        if (this.shouldFail) {
            throw this.failureError!;
        }
        return this.chargeResult!;
    }
}
 
class MockLogger implements Logger {
    infoMessages: string[] = [];
    errorMessages: string[] = [];
    
    info(message: string): void {
        this.infoMessages.push(message);
    }
    
    error(message: string): void {
        this.errorMessages.push(message);
    }
    
    // Test helper
    reset(): void {
        this.infoMessages = [];
        this.errorMessages = [];
    }
}
 
class MockAuditService implements AuditService {
    recordedTransactions: PaymentResult[] = [];
    
    async recordTransaction(result: PaymentResult): Promise<void> {
        this.recordedTransactions.push(result);
    }
}
 
describe('PaymentProcessor', () => {
    let mockGateway: MockPaymentGateway;
    let mockLogger: MockLogger;
    let mockAudit: MockAuditService;
    let processor: PaymentProcessor;
    
    beforeEach(() => {
        // Fresh mocks for each test - complete isolation
        mockGateway = new MockPaymentGateway();
        mockLogger = new MockLogger();
        mockAudit = new MockAuditService();
        
        // Inject mocks instead of real dependencies
        processor = new PaymentProcessor(mockGateway, mockLogger, mockAudit);
    });
    
    describe('successful payment processing', () => {
        it('should return payment result from gateway', async () => {
            // Arrange: Configure mock behavior
            const expectedResult: PaymentResult = {
                transactionId: 'txn_123',
                amount: 100,
                status: 'success',
            };
            mockGateway.setChargeResult(expectedResult);
            
            // Act: Execute the unit under test
            const result = await processor.processPayment(100, 'tok_visa');
            
            // Assert: Verify the result
            expect(result).toEqual(expectedResult);
        });
        
        it('should record successful transaction in audit service', async () => {
            const expectedResult: PaymentResult = {
                transactionId: 'txn_456',
                amount: 250,
                status: 'success',
            };
            mockGateway.setChargeResult(expectedResult);
            
            await processor.processPayment(250, 'tok_mastercard');
            
            // Verify interaction with dependency
            expect(mockAudit.recordedTransactions).toHaveLength(1);
            expect(mockAudit.recordedTransactions[0]).toEqual(expectedResult);
        });
        
        it('should log processing start and success', async () => {
            const result: PaymentResult = {
                transactionId: 'txn_789',
                amount: 500,
                status: 'success',
            };
            mockGateway.setChargeResult(result);
            
            await processor.processPayment(500, 'tok_amex');
            
            expect(mockLogger.infoMessages).toHaveLength(2);
            expect(mockLogger.infoMessages[0]).toContain('Processing payment of 500');
            expect(mockLogger.infoMessages[1]).toContain('Payment successful: txn_789');
        });
    });
    
    describe('failed payment processing', () => {
        it('should propagate gateway errors', async () => {
            // Arrange: Configure failure scenario
            const gatewayError = new Error('Card declined');
            mockGateway.setFailure(gatewayError);
            
            // Act & Assert: Verify error propagation
            await expect(
                processor.processPayment(100, 'tok_declined')
            ).rejects.toThrow('Card declined');
        });
        
        it('should log error when payment fails', async () => {
            mockGateway.setFailure(new Error('Insufficient funds'));
            
            await expect(
                processor.processPayment(100, 'tok_insufficient')
            ).rejects.toThrow();
            
            expect(mockLogger.errorMessages).toHaveLength(1);
            expect(mockLogger.errorMessages[0]).toContain('Payment failed');
        });
        
        it('should not record failed transactions', async () => {
            mockGateway.setFailure(new Error('Network error'));
            
            await expect(
                processor.processPayment(100, 'tok_error')
            ).rejects.toThrow();
            
            // Audit service should not be called on failure
            expect(mockAudit.recordedTransactions).toHaveLength(0);
        });
    });
});

Key observations about these tests:

Characteristics of DIP-Enabled Tests

•Complete isolation — No network calls, no database connections, no file system access. Tests run in milliseconds.
•Full control — We precisely configure how mocks behave, enabling testing of any scenario including edge cases and error conditions.
•Interaction verification — We can verify exactly how the unit interacts with its dependencies (what was logged, what was audited).
•Deterministic — Tests always produce the same results because there are no external variables.
•Fast feedback — The entire test suite runs in under a second, enabling continuous testing during development.

Mock Injection Patterns

There are several patterns for implementing mock injection, each with distinct tradeoffs. Understanding these patterns helps you choose the right approach for your testing context.

Constructor injection is the gold standard for mock injection. Dependencies are provided through the constructor, making them explicit and immutable.

TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ✅ Constructor Injection - Dependencies are explicit and immutable
class OrderService {
    constructor(
        private readonly repository: OrderRepository,
        private readonly paymentService: PaymentService,
        private readonly notificationService: NotificationService
    ) {}
    
    async placeOrder(order: Order): Promise<OrderConfirmation> {
        // Use injected dependencies
        await this.paymentService.process(order.payment);
        const savedOrder = await this.repository.save(order);
        await this.notificationService.sendConfirmation(savedOrder);
        return new OrderConfirmation(savedOrder);
    }
}
 
// Test: Simply pass mocks through constructor
const service = new OrderService(mockRepo, mockPayment, mockNotification);

•✅ Explicit dependencies — All dependencies are visible in the constructor signature
•✅ Immutable — Dependencies cannot be changed after construction
•✅ Compile-time safety — Missing dependencies cause compilation/instantiation errors
•✅ Simple testing — Just pass mocks to the constructor

Pattern Selection Guideline

Use constructor injection by default for required dependencies. Use setter injection for truly optional dependencies with sensible defaults. Use method injection when the dependency legitimately varies per method call. Constructor injection is testable, explicit, and enables immutability—making it the right choice in the vast majority of cases.

Hand-Written vs Framework Mocks

When implementing mock injection, you have a choice between hand-written mocks (as shown in previous examples) and mocking frameworks. Both approaches work with DIP-compliant code, but they have different characteristics.

Hand-Written Mocks

•Full control — You implement exactly what you need
•Type safety — Compile-time verification of interface compliance
•Readable — Mock behavior is explicit in code
•Reusable — Share mocks across test files
•Debuggable — Easy to step through mock logic
•More setup code — Must implement all interface methods

Mocking Frameworks

•Less boilerplate — Generate mocks automatically
•Dynamic configuration — Change behavior per test easily
•Verification helpers — Built-in interaction verification
•Auto-stubbing — Default implementations provided
•Learning curve — Framework-specific API to learn
•Magic behavior — Can hide interface violations

FrameworkMockExample
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
// Using Vitest's mocking capabilities with DIP-compliant code
import { describe, it, expect, vi, beforeEach, Mock } from 'vitest';
 
describe('PaymentProcessor with Framework Mocks', () => {
    let mockGateway: PaymentGateway;
    let mockLogger: Logger;
    let mockAudit: AuditService;
    let processor: PaymentProcessor;
    
    beforeEach(() => {
        // Create mocks using vi.fn() - still implements our interfaces
        mockGateway = {
            charge: vi.fn()
        };
        
        mockLogger = {
            info: vi.fn(),
            error: vi.fn()
        };
        
        mockAudit = {
            recordTransaction: vi.fn()
        };
        
        processor = new PaymentProcessor(mockGateway, mockLogger, mockAudit);
    });
    
    it('should call gateway with correct parameters', async () => {
        const expectedResult: PaymentResult = {
            transactionId: 'txn_test',
            amount: 150,
            status: 'success'
        };
        
        // Configure mock behavior
        (mockGateway.charge as Mock).mockResolvedValue(expectedResult);
        
        await processor.processPayment(150, 'tok_test');
        
        // Verify interaction
        expect(mockGateway.charge).toHaveBeenCalledWith(150, 'tok_test');
        expect(mockGateway.charge).toHaveBeenCalledTimes(1);
    });
    
    it('should verify logging sequence', async () => {
        (mockGateway.charge as Mock).mockResolvedValue({
            transactionId: 'txn_seq',
            amount: 200,
            status: 'success'
        });
        
        await processor.processPayment(200, 'tok_seq');
        
        // Verify call order
        expect(mockLogger.info).toHaveBeenNthCalledWith(
            1, 
            expect.stringContaining('Processing payment of 200')
        );
        expect(mockLogger.info).toHaveBeenNthCalledWith(
            2,
            expect.stringContaining('Payment successful')
        );
    });
});

DIP Makes Both Approaches Viable

Whether you use hand-written mocks or framework mocks, DIP is what makes mock injection possible in the first place. Without interfaces and constructor injection, neither approach would work without resorting to invasive techniques like reflection or monkey-patching.

Summary: Mock Injection Through DIP

We've explored the fundamental connection between the Dependency Inversion Principle and mock injection—the cornerstone of effective unit testing. Let's consolidate the key insights:

Key Takeaways

•Direct dependencies create untestable code — When classes create their own dependencies, you cannot substitute test doubles. Testing requires real databases, real APIs, and real file systems.
•DIP enables substitutability — By depending on abstractions and accepting dependencies through injection, classes become open to having any implementation provided—including test doubles.
•Mock injection requires abstractions — Whether using hand-written mocks or mocking frameworks, the mechanism only works when code depends on interfaces rather than concrete classes.
•Constructor injection is preferred — It makes dependencies explicit, ensures immutability, and provides compile-time verification that all required dependencies are provided.
•Testable code is well-designed code — The same structure that enables mock injection also provides flexibility for production use cases: swapping implementations, feature toggling, and runtime configuration.

What's next:

Mock injection is just the beginning of DIP's impact on testability. In the next page, we'll explore isolating units for testing—how DIP enables you to test each component in complete isolation, verifying behavior without the complexity of integration. We'll examine the boundaries of unit testing, the role of test doubles in creating hermetic tests, and patterns for managing test complexity as systems grow.

Page Complete

You now understand how DIP enables mock injection—the mechanism by which test doubles replace real dependencies during testing. This is the foundation of unit testing in object-oriented systems. Next, we'll explore how to achieve true unit isolation through DIP-compliant design.