Mocking Dependencies - Learning Module

Loading content...

0/246

Over-Mocking Pitfalls

When Tests Lie

There's a test anti-pattern more insidious than no tests at all: tests that pass when the code is broken. Over-mocked tests create a dangerous illusion of safety. They pass in CI, earning green checkmarks, while the actual system fails in production.

Over-mocking happens gradually. Each mock seems reasonable in isolation. But accumulate enough of them, and you're no longer testing your system—you're testing your mocks. The test suite becomes a parallel universe, disconnected from how the code actually behaves.

This page examines how to recognize over-mocking, understand its costs, and recover when you've gone too far.

The Hidden Danger

Over-mocked tests often have high code coverage numbers, pass reliably in CI, and look thoroughly professional. Their danger lies precisely in this appearance of quality. Teams may not realize their test suite has become meaningless until production incidents reveal the gap.

What Is Over-Mocking?

Over-mocking occurs when mocks replace so much of the system that tests no longer exercise meaningful behavior. The tests become self-referential—verifying that mocks behave as configured, rather than that production code works correctly.

Characteristics of over-mocked tests:

Over-Mocking Symptoms

•Mock setup dominates test code — More lines configuring mocks than making assertions about behavior.
•Tests never fail — Even when you intentionally break production code, tests still pass.
•Tests and implementation are tightly coupled — Any refactoring requires rewriting tests.
•Assertions verify mock configuration — Tests check that mocks returned what you configured them to return.
•Production bugs slip through — Despite 'good' coverage, bugs regularly escape to production.
•Contributors avoid writing tests — The overhead is too high, so people skip or write minimal tests.
•Tests fail for wrong reasons — Tests break on refactoring but don't catch actual bugs.

The spectrum of mocking:

Mocking exists on a spectrum from underuse to overuse. The goal is to find the productive middle ground:

The Mocking Spectrum
Level	Characteristics	Problems
Under-mocking	Few or no mocks; tests hit real databases, APIs, networks	Slow, flaky, non-deterministic; tests take minutes
Appropriate mocking	External boundaries mocked; internal logic uses real collaborators	Tests are fast, reliable, and catch real bugs
Over-mocking	Nearly everything mocked; tests are isolated from reality	Tests don't catch bugs; high maintenance burden

The Goldilocks Zone

Appropriate mocking mocks the minimum necessary to achieve isolation from slow, flaky, or side-effect-producing dependencies—and no more. It's a balance that requires judgment, not a rule that can be mechanically applied.

The Tautological Test

The most extreme form of over-mocking is the tautological test—a test that can never fail because it verifies only what it sets up. It's the testing equivalent of asking someone 'Did I give you $100?' immediately after handing them $100.

Anatomy of a tautological test:

tautological-test.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
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
// ❌ TAUTOLOGICAL TEST: Cannot possibly fail
describe('UserService', () => {
    it('should get user by id', async () => {
        // Set up mock to return a user
        const mockRepository = mock<UserRepository>();
        const expectedUser = { id: '123', name: 'Alice' };
        when(mockRepository.findById('123')).thenResolve(expectedUser);
        
        // Call the method
        const service = new UserService(instance(mockRepository));
        const result = await service.getUser('123');
        
        // Assert... that we got what we configured the mock to return
        expect(result).toEqual(expectedUser);  // This CANNOT fail!
    });
});
 
// What's being tested? Nothing.
// - If we delete all the code in UserService.getUser(), 
//   we could make the test pass by just returning mockRepository.findById(id)
// - The test doesn't verify any business logic
// - The test doesn't verify error handling
// - The test verifies only that mocks work as configured
 
// ✅ MEANINGFUL TEST: Actually tests something
describe('UserService', () => {
    it('should enrich user with computed display name', async () => {
        const mockRepository = mock<UserRepository>();
        when(mockRepository.findById('123')).thenResolve({
            id: '123',
            firstName: 'Alice',
            lastName: 'Smith',
            email: 'alice@example.com'
        });
        
        const service = new UserService(instance(mockRepository));
        const result = await service.getUser('123');
        
        // Now we're testing actual behavior
        expect(result.displayName).toBe('Alice Smith');
        expect(result.emailDomain).toBe('example.com');
    });
 
    it('should throw when user not found', async () => {
        const mockRepository = mock<UserRepository>();
        when(mockRepository.findById('nonexistent')).thenResolve(null);
        
        const service = new UserService(instance(mockRepository));
        
        await expect(service.getUser('nonexistent'))
            .rejects.toThrow(UserNotFoundError);
    });
 
    it('should cache user on repeated access', async () => {
        const mockRepository = mock<UserRepository>();
        when(mockRepository.findById('123')).thenResolve(user);
        
        const service = new UserService(instance(mockRepository));
        
        await service.getUser('123');
        await service.getUser('123');
        await service.getUser('123');
        
        verify(mockRepository.findById('123')).once();  // Cached!
    });
});

The mutation test:

A powerful technique to detect tautological tests is mutation testing: deliberately break the production code and see if tests fail. If you can delete lines, invert conditions, or change return values without failing tests, those tests are likely tautological.

// Try this exercise:
// 1. Delete the body of the method under test
// 2. Replace it with: return this.repository.findById(id);
// 3. If tests still pass, they're tautological

Ask: What Mutation Would Fail This Test?

For every test, ask: 'What bug in the production code would cause this test to fail?' If you can't identify one, or if only trivially unlikely bugs would be caught, the test may be tautological or too weakly specified.

Implementation Coupling

Over-mocking creates tight coupling between tests and implementation details. When mocks verify specific method calls, parameter values, and call orders, any refactoring—even ones that preserve behavior—breaks tests.

The cost of implementation coupling:

Consequences of Coupled Tests

•Refactoring becomes expensive — Every internal change requires updating tests, even when behavior is unchanged.
•False failures abound — Tests fail for 'wrong reasons'—not because something broke, but because implementation changed.
•Developer velocity decreases — Teams slow down because every PR requires extensive test updates.
•Tests lose trust — When tests break on every change, developers start ignoring failures or deleting tests.
•Innovation is stifled — Developers avoid improvements that would require extensive test rewrites.

implementation-coupling.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
60
61
62
63
64
65
66
67
68
69
70
// ❌ Test coupled to implementation: Breaks on internal refactoring
describe('OrderProcessing', () => {
    it('should process order', async () => {
        const mockInventory = mock<InventoryService>();
        const mockPayment = mock<PaymentService>();
        
        // Test specifies EXACTLY how processing should work internally
        when(mockInventory.check(order.items)).thenResolve({ available: true });
        when(mockInventory.reserve(order.items)).thenResolve({ reserved: true });
        when(mockPayment.authorize(order.total)).thenResolve({ authCode: 'AUTH123' });
        when(mockPayment.capture('AUTH123', order.total)).thenResolve({ success: true });
        when(mockInventory.commit(order.items)).thenResolve();
        
        const processor = new OrderProcessor(
            instance(mockInventory),
            instance(mockPayment)
        );
        
        await processor.processOrder(order);
        
        // OVER-SPECIFIED: Verifies every internal step in exact order
        verify(mockInventory.check(order.items)).calledBefore(mockInventory.reserve);
        verify(mockInventory.reserve(order.items)).calledBefore(mockPayment.authorize);
        verify(mockPayment.authorize(order.total)).calledBefore(mockPayment.capture);
        verify(mockPayment.capture('AUTH123', order.total)).calledBefore(mockInventory.commit);
        verify(mockInventory.commit(order.items)).once();
    });
});
 
// What happens when we refactor?
// - Combine check + reserve into reserveIfAvailable()? Test breaks.
// - Combine authorize + capture into chargePayment()? Test breaks.
// - Add retry logic? Test breaks.
// - Change commit to async background job? Test breaks.
// All behavior-preserving changes break this test.
 
// ✅ Test focused on outcomes: Resilient to internal refactoring
describe('OrderProcessing', () => {
    it('should mark order as completed when successful', async () => {
        const inventoryService = new FakeInventoryService();
        inventoryService.setAvailable(order.items);
        
        const paymentService = new FakePaymentService();
        paymentService.willSucceed();
        
        const processor = new OrderProcessor(inventoryService, paymentService);
        
        const result = await processor.processOrder(order);
        
        // Test verifies OUTCOMES, not internal steps
        expect(result.status).toBe('COMPLETED');
        expect(inventoryService.getReservedFor(order.id)).toEqual(order.items);
        expect(paymentService.getChargedAmount()).toBe(order.total);
    });
 
    it('should not charge payment if inventory unavailable', async () => {
        const inventoryService = new FakeInventoryService();
        inventoryService.setUnavailable();  // Items not available
        
        const paymentService = new FakePaymentService();
        
        const processor = new OrderProcessor(inventoryService, paymentService);
        
        await expect(processor.processOrder(order))
            .rejects.toThrow(InventoryUnavailableError);
        
        // Verify critical invariant: no charge when inventory fails
        expect(paymentService.getChargedAmount()).toBe(0);
    });
});

The difference between outcomes and implementation:

Test Type	Verifies	Resilient To
Outcome-based	Final state, side effects that matter	Internal refactoring, implementation changes
Implementation-based	Method calls, parameters, order	Almost nothing—any change breaks tests

Tests as Documentation

Implementation-coupled tests document HOW the code works today. Outcome-based tests document WHAT the code should do. The former becomes outdated instantly; the latter remains valuable as the system evolves.

The Mock Configuration Maintenance Burden

Over-mocked tests require extensive mock configurations that must be maintained as the codebase evolves. When interfaces change, all tests using those mocks must be updated—regardless of whether the test actually cares about the changed methods.

The cascading update problem:

maintenance-burden.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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// Imagine UserRepository gains a new required method
interface UserRepository {
    findById(id: string): Promise<User | null>;
    findByEmail(email: string): Promise<User | null>;
    save(user: User): Promise<void>;
    delete(id: string): Promise<void>;
    findAll(): Promise<User[]>;  // NEW METHOD ADDED
}
 
// ❌ With over-mocking: EVERY test file needs updates
// test/user-service.test.ts - must add stub for findAll
// test/auth-service.test.ts - must add stub for findAll  
// test/admin-service.test.ts - must add stub for findAll
// test/reporting-service.test.ts - must add stub for findAll
// ... dozens more files
 
describe('UserService', () => {
    it('should get user by id', async () => {
        const mockRepo = mock<UserRepository>();
        
        // Must stub ALL methods, even ones this test doesn't use
        when(mockRepo.findById(any())).thenResolve(user);
        when(mockRepo.findByEmail(any())).thenResolve(null);
        when(mockRepo.save(any())).thenResolve();
        when(mockRepo.delete(any())).thenResolve();
        when(mockRepo.findAll()).thenResolve([]);  // MUST ADD THIS
        
        // ... test that only uses findById
    });
});
 
// ✅ With fakes: One update propagates automatically
class FakeUserRepository implements UserRepository {
    private users = new Map<string, User>();
    
    async findById(id: string): Promise<User | null> {
        return this.users.get(id) ?? null;
    }
    
    async findByEmail(email: string): Promise<User | null> {
        return [...this.users.values()].find(u => u.email === email) ?? null;
    }
    
    async save(user: User): Promise<void> {
        this.users.set(user.id, user);
    }
    
    async delete(id: string): Promise<void> {
        this.users.delete(id);
    }
    
    async findAll(): Promise<User[]> {  // Add here ONCE
        return [...this.users.values()];
    }
    
    // Test utilities
    addUser(user: User): void {
        this.users.set(user.id, user);
    }
    
    clear(): void {
        this.users.clear();
    }
}
 
// All tests using FakeUserRepository work unchanged
describe('UserService', () => {
    it('should get user by id', async () => {
        const repo = new FakeUserRepository();
        repo.addUser({ id: '123', name: 'Alice', email: 'alice@example.com' });
        
        const service = new UserService(repo);
        const result = await service.getUser('123');
        
        expect(result.name).toBe('Alice');
    });
});

The maintenance multiplier:

With mock-heavy tests, every interface change multiplies into updates across many test files:

Interface Change	Over-Mocked Suite	Fake-Based Suite
Add new method	Update N test files × M tests each	Update 1 fake class
Rename method	Update N × M mocks	Find-and-replace in 1 fake
Change signature	Update N × M stubs	Update 1 implementation
Remove method	Update N × M mocks	Remove from 1 fake

Fakes Reduce Maintenance

A well-designed fake is updated in one place and used everywhere. When the interface changes, you update the fake once. Tests that use it continue to work if they don't need the changed functionality, and fail naturally if they do.

Lost Business Logic Testing

Perhaps the most serious consequence of over-mocking is that it allows tests to pass without exercising critical business logic. When mocks short-circuit the actual computation, bugs hide in the untested paths.

The false confidence trap:

lost-business-logic.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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
// ❌ Over-mocked: Business logic not tested
describe('PricingService', () => {
    it('should calculate order total', () => {
        const mockTaxCalculator = mock<TaxCalculator>();
        const mockDiscountEngine = mock<DiscountEngine>();
        const mockShippingCalculator = mock<ShippingCalculator>();
        
        // Mocks return canned values - no real calculation tested
        when(mockTaxCalculator.calculate(any())).thenReturn(10.00);
        when(mockDiscountEngine.apply(any(), any())).thenReturn(15.00);
        when(mockShippingCalculator.calculate(any())).thenReturn(5.99);
        
        const service = new PricingService(
            instance(mockTaxCalculator),
            instance(mockDiscountEngine),
            instance(mockShippingCalculator)
        );
        
        const total = service.calculateTotal(order, 'PROMO10');
        
        // This passes, but what did we actually test?
        // - Did we verify tax is calculated correctly for different states?
        // - Did we verify discount stacking rules?
        // - Did we verify shipping tiers?
        // NO. We verified our mocks return what we configured.
        expect(total).toBe(100.99);  // Passes!
    });
});
 
// Production bug: Tax not applied to discounted amount
// The above test passes, but customers are overcharged
 
// ✅ Real collaborators: Business logic is tested
describe('PricingService', () => {
    let service: PricingService;
 
    beforeEach(() => {
        // Use real implementations - fast, deterministic, no external deps
        service = new PricingService(
            new TaxCalculator(TaxRates.US),
            new DiscountEngine(),
            new ShippingCalculator(ShippingZones.DOMESTIC)
        );
    });
 
    it('should apply tax to discounted subtotal, not original', () => {
        const order = new OrderBuilder()
            .withItem('ITEM-1', 100.00)  // $100 item
            .build();
        
        // 20% discount, then 8% tax
        // Correct: (100 - 20) * 1.08 = 86.40
        // Bug would give: 100 * 1.08 - 20 = 88.00
        
        const total = service.calculateTotal(order, 'PROMO20');
        
        expect(total.subtotal).toBe(80.00);  // After discount
        expect(total.tax).toBe(6.40);        // Tax on discounted amount
        expect(total.grandTotal).toBe(86.40);
    });
 
    it('should not allow stacking percentage and dollar discounts', () => {
        const order = new OrderBuilder()
            .withItem('ITEM-1', 100.00)
            .build();
        
        // Try to stack 20% off with $10 off
        expect(() => service.calculateTotal(order, 'PROMO20', 'SAVE10'))
            .toThrow('Cannot stack discount types');
    });
 
    it('should apply free shipping threshold correctly', () => {
        const smallOrder = new OrderBuilder().withTotal(49.99).build();
        const qualifyingOrder = new OrderBuilder().withTotal(50.00).build();
        
        expect(service.calculateTotal(smallOrder).shipping).toBe(5.99);
        expect(service.calculateTotal(qualifyingOrder).shipping).toBe(0.00);
    });
});

What gets tested with over-mocking:

When everything is mocked, you primarily test:

That the class calls the right methods on its dependencies (implementation coupling)
That the class passes through whatever the mocks return (no logic tested)
That your mock configuration is correctly written (testing test code)

What doesn't get tested:

Actual calculations and business rules
Edge cases in domain logic
Interactions between domain concepts
Error handling for business rule violations

Coverage Lies

Over-mocked tests can achieve high code coverage while testing almost nothing. Every line is 'executed,' but with mocks returning canned values, no real logic is validated. Coverage becomes a vanity metric that hides the absence of meaningful testing.

Signs You're Over-Mocking

Over-mocking creeps in gradually. Recognizing the warning signs early helps you course-correct before tests become unmaintainable.

Code smells in test structure:

Test Code Red Flags

•Mock setup > 50% of test — When more code configures mocks than exercises or asserts, something's wrong.
•Tests need 4+ mocks — A single unit needing many mocks likely violates Single Responsibility Principle.
•Assertions just check mock returns — If you're verifying expect(result).toBe(mockedValue), you've tested nothing.
•verify() outnumbers expect() — Heavy behavioral verification suggests implementation coupling.
•Mocks of mocks — If a mock returns another mock, you've gone too far into the rabbit hole.
•Deep argument matchers — Using any() pervasively or matching complex object structures.
•Tests break on every refactor — If behavior-preserving changes constantly break tests, mocking is too specific.

Process smells:

Process Red Flags

•Production bugs despite passing tests — The suite misses bugs that real usage catches.
•Developers skip or delete tests — Tests are seen as obstacles, not safety nets.
•Test maintenance consumes sprint time — Significant effort goes to updating tests, not adding value.
•Only the author can maintain tests — Complex mock setups require specialized knowledge.
•Tests pass when production code is deleted — The ultimate sign of disconnection.
•PR reviews focus on mock correctness — Discussions are about mock configuration, not behavior.

The Mock Health Self-Assessment
Question	Healthy Answer	Over-Mocking Answer
Can I break prod code and fail tests?	Yes, easily	Tests still pass
How often do tests break on refactoring?	Rarely	Almost always
Can new team members understand tests?	Yes, tests are clear	No, mock setup is opaque
What % of test is setup vs assertion?	< 50%	70%
Do tests document behavior?	Yes, clearly	No, they document mocks
Can I add features without rewriting tests?	Usually	Never

The Delete Test

Periodically delete a random chunk of production code and run tests. If tests don't fail, your suite has a coverage illusion. This 'mutation testing lite' quickly reveals gaps in meaningful coverage.

Recovering from Over-Mocking

If your test suite is over-mocked, don't despair. Recovery is possible through systematic refactoring. The key is incremental improvement, not big-bang rewrites.

Recovery strategies:

Steps to Recover

•Identify the worst offenders — Find tests with the most mocks, the most verify() calls, or that never fail. Start there.
•Replace mocks with fakes — Create simple in-memory implementations that provide more realistic behavior.
•Reduce mock verification — Change verify() calls to state assertions where possible.
•Test at higher levels — Some over-mocked unit tests should become integration tests. Combine units and test outcomes.
•Refactor production code — Classes needing many mocks have too many responsibilities. Split them up.
•Add integration tests — Cover critical paths with tests that use fewer mocks, providing confidence that mocked tests miss.
•Apply the testing pyramid — Ensure you have the right mix: many focused unit tests, fewer broad integration tests.

recovery-example.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
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
// BEFORE: Over-mocked, brittle test
describe('CheckoutService - BEFORE', () => {
    it('completes checkout', async () => {
        const mockCart = mock<CartService>();
        const mockInventory = mock<InventoryService>();
        const mockPayment = mock<PaymentService>();
        const mockShipping = mock<ShippingService>();
        const mockNotification = mock<NotificationService>();
        const mockAnalytics = mock<AnalyticsService>();
        
        // 50 lines of mock configuration...
        when(mockCart.getItems()).thenReturn(items);
        when(mockInventory.reserve(any())).thenResolve();
        // ... etc...
        
        const service = new CheckoutService(
            instance(mockCart),
            instance(mockInventory),
            instance(mockPayment),
            instance(mockShipping),
            instance(mockNotification),
            instance(mockAnalytics)
        );
        
        await service.checkout(userId);
        
        // 20 lines of verification...
        verify(mockNotification.sendConfirmation(any())).once();
        // ... etc...
    });
});
 
// AFTER: Focused tests with strategic fakes
describe('CheckoutService - AFTER', () => {
    // Shared fakes with sensible defaults
    let cartService: FakeCartService;
    let inventoryService: FakeInventoryService;
    let paymentService: FakePaymentService;
    let notifications: CollectingNotificationService;
    let checkoutService: CheckoutService;
 
    beforeEach(() => {
        cartService = new FakeCartService();
        inventoryService = new FakeInventoryService();
        paymentService = new FakePaymentService();
        notifications = new CollectingNotificationService();
        
        checkoutService = new CheckoutService(
            cartService,
            inventoryService,
            paymentService,
            new RealShippingCalculator(),  // Fast, deterministic
            notifications,
            new NoOpAnalytics()  // Analytics isn't tested here
        );
    });
 
    it('should create order from cart items', async () => {
        cartService.add('ITEM-1', 2);
        cartService.add('ITEM-2', 1);
        
        const order = await checkoutService.checkout('user-1');
        
        expect(order.items).toHaveLength(2);
        expect(order.status).toBe('COMPLETED');
    });
 
    it('should send confirmation for completed checkout', async () => {
        cartService.add('ITEM-1', 1);
        
        await checkoutService.checkout('user-1');
        
        expect(notifications.sentTo('user-1')).toBe(true);
        expect(notifications.lastMessage()).toContain('Order confirmed');
    });
 
    it('should not send confirmation if payment fails', async () => {
        cartService.add('ITEM-1', 1);
        paymentService.willDecline();
        
        await expect(checkoutService.checkout('user-1'))
            .rejects.toThrow(PaymentDeclinedError);
        
        expect(notifications.messageCount()).toBe(0);
    });
});

Incremental Is Key

Don't try to fix the entire test suite at once. Improve tests as you touch code for features or bug fixes. Over time, the healthy patterns spread and the problematic tests get replaced.

Summary: Avoiding the Over-Mocking Trap

Over-mocking is a subtle trap that turns tests from assets into liabilities. Let's consolidate the key insights:

Key Takeaways

•Tautological tests provide false confidence — Tests that just verify mock configuration catch zero bugs.
•Implementation coupling stifles refactoring — Tests that verify 'how' instead of 'what' break on every change.
•Maintenance burden multiplies with mocks — Interface changes cascade into updates across many test files.
•Business logic goes untested — When everything is mocked, real calculations and rules aren't validated.
•Warning signs are visible — Excessive setup, never-failing tests, and implementation-focused verification are red flags.
•Recovery is possible — Replace mocks with fakes, reduce verification, test at appropriate levels, and refactor production code.
•Balance is key — Mock external boundaries; keep internal domain logic real. Test outcomes, not implementation.

The mocking philosophy:

Good mocking is like good abstraction—you should barely notice it's there. Tests should read as descriptions of behavior, with mocking serving quietly in the background to enable isolation. When mocking dominates the test, something has gone wrong.

Remember: tests exist to catch bugs and enable refactoring. If over-mocking prevents both, you're paying the cost of testing without receiving the benefits.

What you've learned in this module:

Over this module, you've developed a comprehensive understanding of mocking dependencies:

Why mocking is essential for unit testing and design feedback
The landscape of mocking frameworks across languages
Best practices for effective, maintainable mocking
Pitfalls of over-mocking and how to avoid them

With this foundation, you can now mock thoughtfully—enabling fast, reliable tests that genuinely validate your code's behavior.

Module Complete

Congratulations! You've completed the Mocking Dependencies module. You now understand when and why to mock, how to use mocking frameworks effectively, best practices for maintainable tests, and the warnings signs of over-mocking. Apply these principles to build test suites that provide genuine confidence without becoming maintenance burdens.