Why We Mock Dependencies - Mocking Dependencies | OneNoughtOne

0/246

System Design (LLD)Mocking Dependencies

Mocking Dependencies in Object-Oriented Testing

LevelIntermediate

Duration60 mins

TopicMocking Dependencies

1 / 4

Why We Mock Dependencies

The Isolation Imperative

Consider a simple scenario: you're testing a PaymentProcessor class that validates credit cards, calculates taxes, charges payment gateways, sends confirmation emails, and logs transactions to a database. How do you test this class in isolation? If you call the real payment gateway, you'll be charged real money. If you send real emails, you'll spam actual inboxes. If you write to the real database, you'll pollute production data.

This is the fundamental problem that mocking solves.

Mocking is not merely a testing convenience—it's a design discipline that enables true unit isolation, fast feedback loops, and the validation of behavior contracts between collaborating objects. When done correctly, mocking transforms testing from an afterthought into a powerful design tool.

What You Will Learn

By the end of this page, you will understand why mocking is essential for unit testing, the conceptual foundations of dependency isolation, the relationship between mocking and good design, and how to reason about when mocking is appropriate versus when it becomes a design smell.

The Problem of External Dependencies

Object-oriented systems are composed of collaborating objects. A PaymentProcessor might depend on an AuthorizationService, a TaxCalculator, a PaymentGateway, an EmailNotifier, and a TransactionLogger. Each of these dependencies introduces complexity that makes testing difficult:

External dependencies create testing challenges:

Testing Challenges from Dependencies

•Non-determinism — Network calls can timeout, databases can be down, external services return different results at different times. Tests become flaky and unreliable.
•Slowness — Real database queries, HTTP requests, and file I/O take orders of magnitude longer than in-memory operations. Tests that should run in milliseconds take seconds or minutes.
•Side Effects — Sending real emails, charging real payment gateways, or writing to production databases during tests creates unacceptable consequences.
•Setup Complexity — Configuring real databases, spinning up external services, and managing test data becomes a significant burden that discourages testing.
•Coupling — When tests use real dependencies, failures in those dependencies cause cascading test failures, obscuring the actual location of bugs.

The dependency graph explosion:

Consider what happens when testing without mocks. Your PaymentProcessor depends on PaymentGateway, which depends on HttpClient, which depends on ConnectionPool, which depends on NetworkConfiguration. To test PaymentProcessor, you must configure the entire transitive dependency graph—potentially dozens of objects across multiple layers.

This is not unit testing. This is integration testing wearing a unit test's clothing.

dependency-complexity.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Without mocking: Testing PaymentProcessor requires the entire dependency tree
class PaymentProcessor {
    constructor(
        private gateway: PaymentGateway,      // Needs real HTTP connection
        private emailer: EmailNotifier,        // Sends real emails
        private logger: TransactionLogger,     // Needs real database
        private taxCalc: TaxCalculator,       // May call external tax API
        private auth: AuthorizationService    // Needs real auth server
    ) {}
 
    async processPayment(order: Order): Promise<PaymentResult> {
        // Every dependency must be real and configured
        const authorized = await this.auth.authorize(order.userId);
        const tax = await this.taxCalc.calculate(order);
        const result = await this.gateway.charge(order.total + tax);
        await this.emailer.sendConfirmation(order, result);
        await this.logger.logTransaction(order, result);
        return result;
    }
}
 
// To test processPayment without mocks, you need:
// - Running auth server with test credentials
// - Tax API access (possibly rate-limited)
// - Payment gateway sandbox (still makes real network calls)
// - Email server or test inbox
// - Database with correct schema
 
// This isn't testing PaymentProcessor's logic—
// it's testing whether your infrastructure works.

Integration Testing vs Unit Testing

Integration tests that exercise real dependencies are valuable—but they serve a different purpose than unit tests. Unit tests verify that individual components behave correctly in isolation. Integration tests verify that components work together correctly. Conflating these leads to slow, fragile, and unhelpful test suites.

The Unit Testing Philosophy

Unit testing rests on a fundamental principle: test one thing at a time. When a test fails, you should know immediately and precisely what is broken. This principle drives the need for isolation and, consequently, for mocking.

What makes a test a 'unit' test?

The term 'unit' is deliberately vague in the testing literature. Some interpret it as a single method, others as a single class, and still others as a single behavior or use case. We adopt a pragmatic definition:

A unit test exercises the smallest piece of testable software in isolation from other parts of the system.

The key phrase is 'in isolation.' Isolation means that when the test runs, only the code under test can cause it to fail—not network issues, database quirks, or bugs in dependencies.

Characteristics of True Unit Tests
Characteristic	Isolated (Mocked Dependencies)	Non-Isolated (Real Dependencies)
Speed	Milliseconds per test	Seconds or more per test
Determinism	Always same result for same code	May vary with network, timing, data
Failure Location	Points directly to broken code	Could be code, dependency, or config
Setup Complexity	Minimal—inject test doubles	Complex—configure all dependencies
Parallelization	Trivial—no shared state	Difficult—shared databases, ports
Feedback Cycle	Run hundreds per second	Run tens per minute at best

The FIRST principles of unit testing:

Good unit tests adhere to the FIRST principles, each of which is enabled by proper mocking:

FIRST Principles

•Fast — Tests must run quickly. A suite of 5000 tests should complete in seconds, not hours. This is only possible when network, database, and file I/O are mocked.
•Isolated/Independent — Each test must run in isolation, with no dependency on the order of execution or results of other tests. Mocking prevents shared state leakage.
•Repeatable — Tests must produce the same result every time, regardless of time, network conditions, or environment. Mocking provides deterministic responses.
•Self-Validating — Tests must have a clear pass/fail outcome with no manual inspection required. Mocked dependencies provide predictable, verifiable interactions.
•Timely — Tests should be written at the same time as (or before) the production code. This is only practical when setup is simple—i.e., when dependencies are mocked.

The Fast Feedback Loop

Fast tests enable a tight feedback loop: code → test → refactor → repeat. When tests take seconds, developers run them constantly and catch bugs immediately. When tests take minutes, developers run them rarely and bugs accumulate. Mocking is what makes millisecond tests possible.

Dependency Inversion and Testability

Mocking is inseparable from good object-oriented design. Specifically, it depends on the Dependency Inversion Principle (DIP): high-level modules should not depend on low-level modules; both should depend on abstractions.

When a class depends on concrete implementations, mocking is difficult or impossible. When a class depends on abstractions (interfaces or abstract classes), test doubles can easily substitute for real implementations.

Dependency Inversion enables mocking:

Concrete Dependencies (Hard to Mock)

•PaymentProcessor creates new StripeGateway()
•Cannot substitute test double
•Must configure actual Stripe sandbox
•Tests require network access
•Tightly coupled to Stripe implementation

Abstract Dependencies (Easy to Mock)

•PaymentProcessor receives IPaymentGateway
•Test provides MockPaymentGateway
•No external configuration needed
•Tests run entirely in-memory
•Loosely coupled to any gateway implementation

dependency-inversion.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
// ❌ BEFORE: Concrete dependency - Hard to test
class PaymentProcessor {
    private gateway = new StripePaymentGateway(); // Hardcoded concrete class
 
    async process(amount: number): Promise<PaymentResult> {
        return this.gateway.charge(amount);  // Always calls real Stripe
    }
}
 
// Testing this requires a real Stripe connection - not a unit test!
 
// ✅ AFTER: Abstract dependency - Easy to test
interface IPaymentGateway {
    charge(amount: number): Promise<PaymentResult>;
}
 
class PaymentProcessor {
    constructor(private gateway: IPaymentGateway) {} // Depends on abstraction
 
    async process(amount: number): Promise<PaymentResult> {
        return this.gateway.charge(amount);  // Calls whatever was injected
    }
}
 
// Now testing is trivial:
class MockPaymentGateway implements IPaymentGateway {
    lastChargedAmount?: number;
    shouldFail = false;
 
    async charge(amount: number): Promise<PaymentResult> {
        this.lastChargedAmount = amount;
        if (this.shouldFail) {
            return { success: false, error: "Mock failure" };
        }
        return { success: true, transactionId: "mock-tx-123" };
    }
}
 
// Test example:
describe("PaymentProcessor", () => {
    it("should pass amount to gateway", async () => {
        const mockGateway = new MockPaymentGateway();
        const processor = new PaymentProcessor(mockGateway);
 
        await processor.process(100);
 
        expect(mockGateway.lastChargedAmount).toBe(100);
    });
 
    it("should handle gateway failures", async () => {
        const mockGateway = new MockPaymentGateway();
        mockGateway.shouldFail = true;
        const processor = new PaymentProcessor(mockGateway);
 
        const result = await processor.process(100);
 
        expect(result.success).toBe(false);
    });
});

The seam concept:

Michael Feathers, in Working Effectively with Legacy Code, introduces the concept of a seam: a place in the code where behavior can be altered without modifying the source code. Interfaces and constructor injection create seams. When dependencies are injected rather than instantiated internally, tests can exploit these seams to substitute test doubles.

Code with few seams is hard to test. Code with many seams—achieved through proper dependency inversion—is a pleasure to test.

Testability as a Design Quality

If a class is hard to test, it often indicates a design problem. Classes that create their own dependencies, access global state, or have hidden side effects are not only hard to test—they're also hard to understand, maintain, and extend. Mocking difficulty is a design smell.

What Mocking Actually Means

The term 'mocking' is often used loosely to refer to any test double, but it has a specific meaning in the testing taxonomy. Understanding this distinction helps you choose the right tool for each testing scenario.

The taxonomy of test doubles:

Gerard Meszaros, in xUnit Test Patterns, defines five types of test doubles. 'Mock' is just one:

Test Double Taxonomy
Type	Purpose	Verification	Example Use Case
Dummy	Fill parameter lists	None—never actually used	Passing null or empty objects to satisfy signatures
Stub	Provide canned responses	State verification	Return a fixed user object for any ID
Spy	Record calls for later verification	Behavior verification (after)	Check if email was sent with correct content
Mock	Pre-programmed expectations	Behavior verification (before)	Fail if charge() not called with exact amount
Fake	Working but simplified implementation	Usually state	In-memory database, lightweight alternative

The distinction between state and behavior verification:

The fundamental difference between these doubles lies in how they verify correctness:

State verification checks the final state of the system after the action. "After calling processPayment(), is order.status equal to 'paid'?"
Behavior verification checks that certain interactions occurred. "Was paymentGateway.charge() called exactly once with $100?"

Mocks (in the strict sense) use behavior verification with pre-programmed expectations. Stubs and spies typically use state verification or post-hoc interaction checking.

state-vs-behavior.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// State Verification: Check the resulting state
describe("Order", () => {
    it("should be marked as paid after successful payment", async () => {
        // Arrange
        const stubGateway = new StubPaymentGateway();
        stubGateway.stubbedResult = { success: true };
        const order = new Order(stubGateway);
 
        // Act
        await order.pay();
 
        // Assert: Verify STATE
        expect(order.status).toBe("paid");
    });
});
 
// Behavior Verification: Check the interactions occurred
describe("Order", () => {
    it("should charge the gateway with order total", async () => {
        // Arrange
        const mockGateway = mock<IPaymentGateway>();
        when(mockGateway.charge(100)).thenReturn({ success: true });
        const order = new Order(mockGateway, { total: 100 });
 
        // Act
        await order.pay();
 
        // Assert: Verify BEHAVIOR
        verify(mockGateway.charge(100)).once();
    });
});
 
// Both are valid—but they verify different things:
// - State verification: Does the order end up in the right state?
// - Behavior verification: Does the order interact correctly with collaborators?

When to Use Each

Prefer state verification when testing the observable outcomes of an operation. Use behavior verification when the interaction with a collaborator is the essential behavior being tested—such as verifying that a notification was sent or an audit log was written. Over-relying on behavior verification leads to brittle tests that break when implementation details change.

The Benefits of Mocking

Mocking provides numerous benefits that extend beyond simply making tests run. Understanding these benefits helps you appreciate why mocking is a fundamental skill for professional software development.

Primary benefits of mocking dependencies:

Benefits of Proper Mocking

•Speed — In-memory test doubles execute in nanoseconds. Real network calls take milliseconds to seconds. A test suite with 10,000 tests can run in seconds with mocks, enabling continuous testing during development.
•Determinism — Mocks always return what you configure them to return. No more 'works on my machine' failures due to database state differences, network timeouts, or race conditions.
•Isolation — When a test fails, the failure is localized to the code under test. You don't waste hours debugging whether the failure is in your code, a dependency, the network, or the test data.
•Control — Mocks let you simulate conditions that are hard to reproduce with real systems: network failures, database timeouts, rare error conditions, edge cases in external APIs.
•Parallelization — Tests with mocks have no shared state and can run in parallel without interference. This dramatically reduces total test suite runtime.
•Cost Reduction — Real API calls often cost money (payment processors, cloud services, SMS gateways). Mocks eliminate these costs entirely during development.

Enabling edge case testing:

Perhaps the most underappreciated benefit of mocking is the ability to test edge cases and error conditions. How do you test that your application handles a database timeout gracefully? With a real database, you'd have to somehow cause a timeout—perhaps by overloading the server or introducing network latency. With a mock, you simply configure it to throw a timeout exception:

testing-edge-cases.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
describe("OrderService", () => {
    // Testing the happy path
    it("should complete order when payment succeeds", async () => {
        const mockGateway = createMock<IPaymentGateway>();
        mockGateway.charge.mockResolvedValue({ success: true });
 
        const service = new OrderService(mockGateway);
        const result = await service.completeOrder(order);
 
        expect(result.status).toBe("completed");
    });
 
    // Testing error conditions - trivial with mocks, hard with real dependencies
    it("should retry on temporary network failure", async () => {
        const mockGateway = createMock<IPaymentGateway>();
        mockGateway.charge
            .mockRejectedValueOnce(new NetworkTimeoutError())
            .mockResolvedValue({ success: true });
 
        const service = new OrderService(mockGateway);
        const result = await service.completeOrder(order);
 
        expect(mockGateway.charge).toHaveBeenCalledTimes(2);
        expect(result.status).toBe("completed");
    });
 
    it("should fail gracefully on gateway outage", async () => {
        const mockGateway = createMock<IPaymentGateway>();
        mockGateway.charge.mockRejectedValue(new ServiceUnavailableError());
 
        const service = new OrderService(mockGateway);
        const result = await service.completeOrder(order);
 
        expect(result.status).toBe("payment_failed");
        expect(result.error).toBe("Payment service temporarily unavailable");
    });
 
    it("should handle fraudulent transaction response", async () => {
        const mockGateway = createMock<IPaymentGateway>();
        mockGateway.charge.mockResolvedValue({ 
            success: false, 
            reason: "suspected_fraud" 
        });
 
        const service = new OrderService(mockGateway);
        const result = await service.completeOrder(order);
 
        expect(result.status).toBe("flagged_for_review");
    });
});

Testing Failure Paths

Production systems encounter network failures, timeouts, and edge cases that are nearly impossible to reproduce reliably in integration tests. Mocking allows you to exhaustively test these failure paths, ensuring your system degrades gracefully when dependencies misbehave.

Mocking as Design Feedback

Beyond enabling tests, mocking serves as a powerful design feedback mechanism. The difficulty of mocking a dependency often reveals design problems that would otherwise remain hidden until the system grows complex enough to cause pain.

Mocking difficulty signals design issues:

Mocking Difficulties and Their Design Implications
Mocking Difficulty	Likely Design Problem	Suggested Refactoring
Too many mocks needed for one test	Class has too many responsibilities	Apply Single Responsibility Principle; extract classes
Mock setup is complex and verbose	Interface is too large or complex	Apply Interface Segregation Principle; break into smaller interfaces
Cannot inject mock (no constructor injection)	Class creates its own dependencies	Apply Dependency Inversion; inject dependencies
Mocking requires accessing private members	Testing implementation details, not behavior	Test through public interface; redesign if necessary
Tests break when mock's internal behavior changes	Over-specifying interactions	Verify outcomes, not interactions; use state verification
Cannot mock static methods or singletons	Overuse of static state	Replace statics with injectable services

The litmus test for good design:

If you can write a test for a class using simple, hand-written test doubles without resorting to complex mocking frameworks or reflection tricks, the class has a clean design. If mocking requires heroic efforts—partial mocks, power mocking, mock injection frameworks—the design likely has issues.

This feedback loop is invaluable: it surfaces design problems during testing, when they're cheap to fix, rather than in production, when they're expensive.

design-feedback.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
// ❌ Design smell: Method that's hard to mock
class ReportGenerator {
    generate(): Report {
        // Calls static method - can't be mocked easily
        const data = DatabaseConnection.getInstance().query("...");
        
        // Calls another static method
        const formatted = ReportFormatter.formatAsHtml(data);
        
        // Creates concrete instance - can't substitute
        const sender = new EmailSender();
        sender.send(formatted);
        
        // Uses system call directly
        const timestamp = new Date().toISOString();
        
        return new Report(data, timestamp);
    }
}
 
// Testing this requires: mocking statics, mocking constructors, 
// freezing time—complex heroics that indicate design problems
 
// ✅ Refactored design: Easy to mock, better separation
class ReportGenerator {
    constructor(
        private repository: IReportRepository,     // Abstraction, injectable
        private formatter: IReportFormatter,       // Abstraction, injectable  
        private notifier: INotifier,               // Abstraction, injectable
        private clock: IClock                      // Even time is injectable
    ) {}
 
    generate(): Report {
        const data = this.repository.getReportData();
        const formatted = this.formatter.format(data);
        this.notifier.notify(formatted);
        const timestamp = this.clock.now().toISOString();
        return new Report(data, timestamp);
    }
}
 
// Now testing is trivial—each dependency can be a simple stub
describe("ReportGenerator", () => {
    it("should format data from repository", () => {
        const stubRepo = { getReportData: () => testData };
        const stubFormatter = { format: (d) => "formatted: " + d };
        const stubNotifier = { notify: jest.fn() };
        const stubClock = { now: () => new Date("2024-01-01") };
 
        const generator = new ReportGenerator(
            stubRepo, stubFormatter, stubNotifier, stubClock
        );
        const report = generator.generate();
 
        expect(report.timestamp).toBe("2024-01-01T00:00:00.000Z");
    });
});

Listen to the Tests

When tests are painful to write, they're giving you a message about your design. Instead of forcing the test with complex mocking techniques, refactor the production code to be more testable. The resulting design will not only be easier to test—it will be more flexible, maintainable, and comprehensible.

The Testing Pyramid and Mocking

Mocking plays a specific role in the broader testing strategy captured by the testing pyramid. Understanding where mocking fits helps you build a balanced, effective test suite.

The testing pyramid:

The testing pyramid, popularized by Mike Cohn, suggests that a healthy test suite has many unit tests (fast, isolated, mocked), fewer integration tests (some real dependencies), and even fewer end-to-end tests (all real, slow, flaky).

Testing Pyramid Layers
Layer	Speed	Isolation	Mocking Usage	What It Validates
Unit Tests (Base)	Milliseconds	Complete	Heavy—all dependencies mocked	Individual component logic
Integration Tests (Middle)	Seconds	Partial	Moderate—some real, some mocked	Component interactions
E2E Tests (Top)	Minutes	None	None—all real dependencies	Full user flows

Why the pyramid shape matters:

The pyramid is wide at the base (many unit tests) and narrow at the top (few E2E tests) because of the tradeoffs involved:

Unit tests are cheap, fast, and reliable. You can have thousands. They pinpoint failures precisely.
E2E tests are expensive, slow, and fragile. You should have few. They validate broad flows but localize failures poorly.

Mocking enables the large base of the pyramid. Without mocking, you'd be stuck with the inverted 'ice cream cone' anti-pattern: few unit tests and many slow, flaky integration tests.

Balanced Test Strategy

•Unit tests (70-80%) — Heavily mocked, test logic in isolation, run in milliseconds, catch ~60% of bugs
•Integration tests (15-20%) — Selectively mocked, test component boundaries, run in seconds, catch ~30% of bugs
•E2E tests (5-10%) — No mocking, test user flows, run in minutes, catch ~10% of bugs but validate production-like behavior

The Ice Cream Cone Anti-Pattern

Teams without mocking skills often build the 'ice cream cone'—a few unit tests and many slow integration/E2E tests. This leads to slow feedback cycles, flaky CI pipelines, and developers who stop trusting or running tests. Mastering mocking enables the healthy pyramid.

Summary: Why We Mock

We've established the philosophical and practical foundations for mocking dependencies. Let's consolidate the key insights:

Key Takeaways

•External dependencies make testing difficult — They introduce non-determinism, slowness, side effects, setup complexity, and coupling that undermine test value.
•Unit tests require isolation — True unit tests exercise the smallest testable piece in isolation, with only the code under test able to cause failures.
•Dependency Inversion enables mocking — When classes depend on abstractions rather than concretions, test doubles can be easily substituted.
•Mocking is a taxonomy — Dummies, stubs, spies, mocks, and fakes each serve different purposes. Choose the right double for each situation.
•Mocking provides control — It enables testing of edge cases, error conditions, and failure paths that are hard to reproduce with real dependencies.
•Mocking difficulty is design feedback — If a class is hard to mock, it probably has design problems worth addressing.
•Mocking enables the testing pyramid — A healthy, fast, reliable test suite depends on heavily-mocked unit tests forming its broad base.

What's next:

Now that we understand why we mock, the next page explores how we mock. We'll survey popular mocking frameworks across languages, understand their capabilities and tradeoffs, and see how to select the right tool for your testing needs.

Page Complete

You now understand the fundamental rationale for mocking dependencies. Mocking isn't just a testing convenience—it's a design discipline that enables fast, reliable, isolated tests and provides ongoing feedback about code quality. Next, we'll explore the practical tools that make mocking straightforward.