Mocking Dependencies - Learning Module

Loading content...

0/246

Mocking Frameworks Overview

The Mocking Ecosystem

While you can write test doubles by hand—and often should for simple cases—mocking frameworks dramatically reduce the boilerplate involved in creating, configuring, and verifying test doubles. These frameworks have evolved sophisticated capabilities: auto-generating mock implementations from interfaces, recording and verifying method calls, matching complex arguments, and providing expressive APIs for test setup.

Understanding the mocking framework landscape empowers you to select the right tool for your language, project characteristics, and testing philosophy. Each framework embodies different tradeoffs between power, simplicity, type safety, and ergonomics.

What You Will Learn

By the end of this page, you will understand the capabilities common to mocking frameworks, survey the most popular frameworks across Java, JavaScript/TypeScript, Python, C#, and other languages, understand the philosophical differences between strict and loose mocking, and learn how to evaluate frameworks for your specific needs.

What Mocking Frameworks Provide

Before diving into specific frameworks, let's understand the core capabilities that distinguish a mocking framework from hand-written test doubles. These capabilities justify the learning curve investment.

Core capabilities of mocking frameworks:

Essential Framework Features

•Automatic Mock Generation — Create mock implementations of interfaces or classes with a single line, without manually implementing every method.
•Stubbing — Configure what the mock should return when specific methods are called with specific arguments. Supports various matching strategies (exact, any, pattern-based).
•Verification — Assert that methods were called with expected arguments, the expected number of times, in the expected order. Detect unexpected or missing calls.
•Argument Matching — Match arguments flexibly: exact values, any value of a type, values matching predicates, captured values for later inspection.
•Spy Functionality — Create partial mocks that delegate some calls to real implementations while intercepting others for verification or stubbing.
•Exception Simulation — Configure mocks to throw exceptions, enabling testing of error handling paths.
•Call Recording — Capture the actual arguments passed to mock methods for complex assertions or debugging.

Hand-written doubles vs framework mocks:

For simple cases, hand-written test doubles are preferable—they're explicit, debuggable, and require no framework knowledge. But as complexity grows, the advantages of frameworks become apparent:

Hand-Written Doubles vs Mocking Frameworks
Aspect	Hand-Written Doubles	Mocking Framework
Setup effort for simple mock	Low—implement a few methods	Low—single line
Setup effort for complex interface	High—implement many methods	Low—still single line
Verifying call count	Manually track in double	Built-in verification API
Matching complex arguments	Manual comparison logic	Rich argument matchers
Testing call order	Complex state machine	Built-in order verification
Debugging failures	Direct stack trace	Framework-specific messages
Type safety	Full compile-time safety	Varies by framework
Learning curve	None	Framework-specific

The Right Tool for the Job

Use hand-written doubles when the interface is small and stable, and when you want maximum explicitness. Use frameworks when interfaces are large, when you need sophisticated verification, or when mocks need to be reconfigured frequently across tests. Many projects use both.

Java Mocking Frameworks

Java has a mature mocking ecosystem, with Mockito being the dominant choice for over a decade. Understanding the Java landscape helps contextualize frameworks in other languages that often drew inspiration from these pioneers.

Mockito — The industry standard:

Mockito is the most widely used mocking framework in Java. It combines a clean, readable API with powerful capabilities and has become the de facto standard for Java unit testing.

mockito-example.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
import static org.mockito.Mockito.*;
 
public class PaymentServiceTest {
    @Test
    void shouldChargeGatewayWithOrderTotal() {
        // Create mock
        PaymentGateway gateway = mock(PaymentGateway.class);
        
        // Stub behavior
        when(gateway.charge(anyDouble()))
            .thenReturn(new PaymentResult(true, "tx-123"));
        
        // Use the mock
        PaymentService service = new PaymentService(gateway);
        PaymentResult result = service.processPayment(99.99);
        
        // Verify interactions
        verify(gateway).charge(99.99);
        verify(gateway, times(1)).charge(anyDouble());
        verify(gateway, never()).refund(any());
        
        // Assert result
        assertTrue(result.isSuccess());
    }
 
    @Test
    void shouldRetryOnTemporaryFailure() {
        PaymentGateway gateway = mock(PaymentGateway.class);
        
        // Consecutive stubbing - different results on each call
        when(gateway.charge(anyDouble()))
            .thenThrow(new TemporaryNetworkException())
            .thenReturn(new PaymentResult(true, "tx-456"));
        
        PaymentService service = new PaymentService(gateway);
        PaymentResult result = service.processPayment(50.00);
        
        // Verify retry occurred
        verify(gateway, times(2)).charge(50.00);
        assertTrue(result.isSuccess());
    }
 
    @Test
    void shouldCaptureArgumentsForComplexAssertion() {
        PaymentGateway gateway = mock(PaymentGateway.class);
        ArgumentCaptor<PaymentRequest> captor = 
            ArgumentCaptor.forClass(PaymentRequest.class);
        
        when(gateway.processRequest(any())).thenReturn(successResult());
        
        PaymentService service = new PaymentService(gateway);
        service.processOrderPayment(complexOrder);
        
        verify(gateway).processRequest(captor.capture());
        PaymentRequest captured = captor.getValue();
        
        assertEquals("USD", captured.getCurrency());
        assertTrue(captured.getAmount() > 0);
    }
}

Other notable Java frameworks:

Java Mocking Framework Comparison
Framework	Philosophy	Key Features	Best For
Mockito	Loose, readable	Simple API, BDD-style (given/when/then), annotations	General purpose, most projects
EasyMock	Record-replay	Strict verification, explicit expectation recording	Teams preferring explicit control
JMockit	Powerful, invasive	Mocks anything (statics, constructors, final classes)	Legacy code with poor design
PowerMock	Extends Mockito/EasyMock	Mocks statics, privates, constructors	Legacy code rescue (use sparingly)
Spock	Groovy-based BDD	Expressive DSL, built-in mocking	Teams using Groovy, prefer BDD

Power Mocking is a Smell

PowerMock and JMockit can mock static methods, constructors, and final classes—things Mockito deliberately cannot. While useful for testing legacy code, needing these capabilities indicates design problems. Rather than reach for PowerMock, consider refactoring the code to be properly injectable.

JavaScript/TypeScript Mocking Frameworks

The JavaScript ecosystem offers several mocking approaches, from built-in capabilities in test runners to standalone libraries. TypeScript adds the challenge of type safety, which some frameworks handle better than others.

Jest — The all-in-one solution:

Jest, developed by Meta, includes comprehensive mocking capabilities built into the test runner, making it the most popular choice for JavaScript testing.

jest-mocking.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
import { PaymentService } from './payment-service';
import { PaymentGateway } from './payment-gateway';
 
// Auto-mock an entire module
jest.mock('./payment-gateway');
 
describe('PaymentService', () => {
    let mockGateway: jest.Mocked<PaymentGateway>;
 
    beforeEach(() => {
        mockGateway = new PaymentGateway() as jest.Mocked<PaymentGateway>;
        jest.clearAllMocks();
    });
 
    it('should charge the gateway with correct amount', async () => {
        // Stub the return value
        mockGateway.charge.mockResolvedValue({ 
            success: true, 
            transactionId: 'tx-123' 
        });
 
        const service = new PaymentService(mockGateway);
        const result = await service.processPayment(99.99);
 
        expect(mockGateway.charge).toHaveBeenCalledWith(99.99);
        expect(mockGateway.charge).toHaveBeenCalledTimes(1);
        expect(result.success).toBe(true);
    });
 
    it('should handle gateway failures', async () => {
        // Stub to throw an error
        mockGateway.charge.mockRejectedValue(new Error('Gateway timeout'));
 
        const service = new PaymentService(mockGateway);
        
        await expect(service.processPayment(50))
            .rejects.toThrow('Gateway timeout');
    });
 
    it('should support consecutive return values', async () => {
        mockGateway.charge
            .mockRejectedValueOnce(new Error('Temporary failure'))
            .mockResolvedValueOnce({ success: true, transactionId: 'tx-456' });
 
        const service = new PaymentService(mockGateway);
        const result = await service.processPaymentWithRetry(100);
 
        expect(mockGateway.charge).toHaveBeenCalledTimes(2);
        expect(result.success).toBe(true);
    });
});
 
// Mock implementation for more control
jest.mock('./notification-service', () => ({
    NotificationService: jest.fn().mockImplementation(() => ({
        sendEmail: jest.fn().mockResolvedValue(true),
        sendSMS: jest.fn().mockResolvedValue(true),
    })),
}));

TypeScript-first alternatives:

For projects prioritizing type safety, alternatives to Jest's mocking offer stronger typing:

JavaScript/TypeScript Mocking Options
Tool	Philosophy	Type Safety	Best For
Jest mocks	Built-in, pragmatic	Partial (manual typing)	Projects already using Jest
Vitest mocks	Jest-compatible, modern	Good with TypeScript	Vite-based projects
ts-mockito	Java Mockito-inspired	Excellent type inference	Strict typing, DI-heavy projects
typemoq	C# Moq-inspired	Strong type safety	Teams from C# background
Substitute.js	Proxy-based	Excellent for interfaces	Minimalist, type-safe needs
Sinon.JS	Standalone, flexible	Moderate	Framework-agnostic testing

ts-mockito-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
import { mock, when, verify, instance, anything, capture } from 'ts-mockito';
import { PaymentGateway } from './payment-gateway';
import { PaymentService } from './payment-service';
 
describe('PaymentService with ts-mockito', () => {
    it('should provide excellent type safety', async () => {
        // Create typed mock
        const mockGateway: PaymentGateway = mock(PaymentGateway);
        
        // Type-safe stubbing - compiler catches errors
        when(mockGateway.charge(anything()))
            .thenResolve({ success: true, transactionId: 'tx-789' });
        
        // Get instance for injection
        const gatewayInstance = instance(mockGateway);
        const service = new PaymentService(gatewayInstance);
        
        await service.processPayment(75.50);
        
        // Type-safe verification
        verify(mockGateway.charge(75.50)).once();
        
        // Capture arguments for complex assertions
        const [capturedAmount] = capture(mockGateway.charge).last();
        expect(capturedAmount).toBe(75.50);
    });
});

Type Safety Matters

When your mock's method signature changes but your tests don't break, you have false confidence. Type-safe mocking frameworks like ts-mockito catch these mismatches at compile time, ensuring your tests stay synchronized with your interfaces.

Python Mocking

Python's dynamic nature makes mocking both easier (no interfaces needed) and more dangerous (no compile-time safety). The standard library includes unittest.mock, making external libraries optional for most use cases.

unittest.mock — The standard library solution:

Python's built-in mocking is powerful and sufficient for most needs. It leverages Python's dynamic typing to patch any attribute at runtime.

python_mocking.py
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
from unittest import TestCase
from unittest.mock import Mock, patch, MagicMock, call
 
from payment_service import PaymentService
from payment_gateway import PaymentGateway
 
 
class TestPaymentService(TestCase):
    
    def test_charges_gateway_with_correct_amount(self):
        # Create mock
        mock_gateway = Mock(spec=PaymentGateway)
        mock_gateway.charge.return_value = {'success': True, 'tx_id': 'tx-123'}
        
        service = PaymentService(mock_gateway)
        result = service.process_payment(99.99)
        
        # Verify call
        mock_gateway.charge.assert_called_once_with(99.99)
        self.assertTrue(result['success'])
    
    def test_handles_gateway_exception(self):
        mock_gateway = Mock(spec=PaymentGateway)
        mock_gateway.charge.side_effect = ConnectionError("Gateway down")
        
        service = PaymentService(mock_gateway)
        
        with self.assertRaises(PaymentFailedError):
            service.process_payment(50.00)
    
    def test_retries_on_temporary_failure(self):
        mock_gateway = Mock(spec=PaymentGateway)
        # Consecutive return values
        mock_gateway.charge.side_effect = [
            ConnectionError("Temporary"),
            {'success': True, 'tx_id': 'tx-456'}
        ]
        
        service = PaymentService(mock_gateway)
        result = service.process_payment_with_retry(100.00)
        
        # Verify two calls occurred
        self.assertEqual(mock_gateway.charge.call_count, 2)
        self.assertTrue(result['success'])
 
 
class TestWithPatching(TestCase):
    
    @patch('payment_service.PaymentGateway')
    def test_patches_module_level_dependency(self, MockGateway):
        """Patch where it's used, not where it's defined"""
        mock_instance = MockGateway.return_value
        mock_instance.charge.return_value = {'success': True}
        
        # PaymentService internally imports PaymentGateway
        service = PaymentService()  # Uses patched version
        result = service.process_payment(25.00)
        
        mock_instance.charge.assert_called_with(25.00)
    
    def test_patches_as_context_manager(self):
        with patch.object(PaymentGateway, 'charge') as mock_charge:
            mock_charge.return_value = {'success': True}
            
            gateway = PaymentGateway()
            result = gateway.charge(50.00)
            
            mock_charge.assert_called_once_with(50.00)
            # Patch is automatically reverted after the block

Critical concept: Patch where it's used, not defined:

Python's patch decorator replaces objects at the location where they are looked up. If payment_service.py does from payment_gateway import PaymentGateway, you must patch payment_service.PaymentGateway, not payment_gateway.PaymentGateway.

This is the most common source of Python mocking bugs and confusion.

Python Mocking Options
Tool	Source	Key Features	Best For
unittest.mock	Standard library	@patch decorator, spec/autospec, MagicMock	Most projects (no dependencies)
pytest-mock	pytest plugin	Fixture-based, cleaner syntax	pytest users
mockito-python	Third-party	Java Mockito-style API	Teams familiar with Mockito
responses	Third-party	HTTP request mocking	Testing HTTP clients specifically
freezegun	Third-party	Time freezing/mocking	Testing time-dependent code

Use spec= to Catch Typos

Plain Mock() accepts any attribute access, even misspelled method names. Using Mock(spec=RealClass) or @patch(..., autospec=True) creates mocks that only accept attributes the real class has, catching typos and outdated tests at runtime.

C# and .NET Mocking Frameworks

The .NET ecosystem features several mature mocking frameworks. Moq dominates in popularity, but alternatives like NSubstitute offer different ergonomics. C#'s strong typing enables excellent IDE support and compile-time safety.

Moq — The most popular choice:

Moq uses lambda expressions to provide a fluent, type-safe API for creating mocks and setting up expectations.

moq-example.cs
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 Moq;
using Xunit;
 
public class PaymentServiceTests
{
    [Fact]
    public async Task ProcessPayment_ShouldChargeGateway_WithCorrectAmount()
    {
        // Arrange
        var mockGateway = new Mock<IPaymentGateway>();
        mockGateway
            .Setup(g => g.ChargeAsync(It.IsAny<decimal>()))
            .ReturnsAsync(new PaymentResult { Success = true, TransactionId = "tx-123" });
 
        var service = new PaymentService(mockGateway.Object);
 
        // Act
        var result = await service.ProcessPaymentAsync(99.99m);
 
        // Assert
        mockGateway.Verify(g => g.ChargeAsync(99.99m), Times.Once);
        Assert.True(result.Success);
    }
 
    [Fact]
    public async Task ProcessPayment_ShouldRetry_OnTemporaryFailure()
    {
        // Arrange
        var mockGateway = new Mock<IPaymentGateway>();
        mockGateway
            .SetupSequence(g => g.ChargeAsync(It.IsAny<decimal>()))
            .ThrowsAsync(new TemporaryNetworkException())
            .ReturnsAsync(new PaymentResult { Success = true });
 
        var service = new PaymentService(mockGateway.Object);
 
        // Act
        var result = await service.ProcessPaymentWithRetryAsync(100m);
 
        // Assert
        mockGateway.Verify(g => g.ChargeAsync(100m), Times.Exactly(2));
        Assert.True(result.Success);
    }
 
    [Fact]
    public void ShouldCaptureArguments_ForComplexAssertions()
    {
        // Arrange
        var mockLogger = new Mock<ITransactionLogger>();
        decimal capturedAmount = 0;
        
        mockLogger
            .Setup(l => l.LogTransaction(It.IsAny<decimal>(), It.IsAny<string>()))
            .Callback<decimal, string>((amount, _) => capturedAmount = amount);
 
        var service = new PaymentService(mockLogger.Object);
 
        // Act
        service.LogPayment(250.75m, "success");
 
        // Assert
        Assert.Equal(250.75m, capturedAmount);
    }
}

NSubstitute — Cleaner syntax:

NSubstitute offers a less verbose alternative to Moq, with mocks that look more like the real interfaces they substitute:

nsubstitute-example.cs
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
using NSubstitute;
using Xunit;
 
public class PaymentServiceNSubstituteTests
{
    [Fact]
    public async Task ProcessPayment_WithNSubstitute()
    {
        // Create substitute - no .Object needed
        var gateway = Substitute.For<IPaymentGateway>();
        
        // Configure return value - reads more naturally
        gateway.ChargeAsync(Arg.Any<decimal>())
            .Returns(new PaymentResult { Success = true });
 
        var service = new PaymentService(gateway);
        var result = await service.ProcessPaymentAsync(75.00m);
 
        // Verify - reads like natural language
        await gateway.Received(1).ChargeAsync(75.00m);
        await gateway.DidNotReceive().RefundAsync(Arg.Any<string>());
        
        Assert.True(result.Success);
    }
}

.NET Mocking Framework Comparison
Framework	API Style	Learning Curve	Best For
Moq	Lambda expressions, Setup/Verify	Moderate	Most .NET projects
NSubstitute	Natural syntax, minimal setup	Low	Clean code enthusiasts
FakeItEasy	Fluent, A.CallTo()	Low	BDD-style testing
JustMock	Commercial, powerful	Moderate	Enterprise, complex mocking needs
Microsoft.Fakes	VS Enterprise feature	High	Legacy code, sealed classes

Strict vs Loose Mocking

Moq defaults to 'loose' mode where unconfigured calls return default values. Use MockBehavior.Strict if you want tests to fail on any unconfigured call—useful for ensuring complete specifications but can make tests more brittle.

Framework Philosophy: Strict vs Loose

Mocking frameworks embody different philosophies about how mocks should behave when interactions aren't explicitly specified. Understanding these philosophies helps you choose frameworks and configure them appropriately.

Loose mocking (default in most modern frameworks):

Unconfigured method calls return sensible defaults (null, empty collections, zero) and don't cause test failures. You only verify the interactions you care about.

Loose Mocking Advantages

•Less test setup boilerplate
•Tests focus on essential interactions
•Tests are more resilient to refactoring
•Easier to write and read
•Encourages testing behavior, not implementation

Loose Mocking Risks

•May miss unexpected interactions
•Typos in method names go unnoticed
•Tests might pass when they shouldn't
•Less explicit about expectations
•Can mask missing dependencies

Strict mocking (record-replay style):

Every interaction must be explicitly specified in advance. Any unexpected call causes the test to fail. This was the default philosophy in older frameworks like EasyMock.

Strict Mocking Advantages

•Complete documentation of interactions
•Catches unexpected calls immediately
•Forces explicit consideration of all calls
•No hidden behavior
•Tests serve as precise contracts

Strict Mocking Risks

•Verbose, tedious test setup
•Brittle—breaks on any implementation change
•Tests become coupled to implementation
•Harder to maintain long-term
•Discourages refactoring

strict-vs-loose.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// Loose mocking (Mockito default): Only verify what you care about
@Test
void looseStyle() {
    PaymentGateway gateway = mock(PaymentGateway.class);
    when(gateway.charge(anyDouble())).thenReturn(success());
    
    PaymentService service = new PaymentService(gateway);
    service.processPayment(100);
    
    // Only verify the essential interaction
    // If service.processPayment internally calls gateway.getStatus(), we don't care
    verify(gateway).charge(100);
}
 
// Strict mocking (EasyMock style): Must specify everything
@Test
void strictStyle() {
    PaymentGateway gateway = strictMock(PaymentGateway.class);
    
    // Must list EVERY expected call
    expect(gateway.isAvailable()).andReturn(true);
    expect(gateway.charge(100)).andReturn(success());
    expect(gateway.getTransactionId()).andReturn("tx-123");
    
    replay(gateway);  // Switch from recording to playback
    
    PaymentService service = new PaymentService(gateway);
    service.processPayment(100);
    
    verify(gateway);  // Verify all expectations met
    // If any unexpected call happens, or expected call missed, test FAILS
}

The Modern Consensus

The industry has largely moved toward loose mocking with selective verification. Strict mocking creates tests that are too tightly coupled to implementation details, making refactoring painful. Verify the interactions that matter; let the rest happen naturally.

Selecting a Mocking Framework

With numerous frameworks available, how do you choose? While personal and team preference matters, several factors should guide your decision:

Decision factors:

Framework Selection Criteria

•Ecosystem integration — Does it work well with your test runner, IDE, and CI system? Jest mocks integrate seamlessly with Jest; pytest-mock integrates with pytest fixtures.
•Type safety — For TypeScript/C#/Java, does the framework provide compile-time checking of mock configurations? Typos in method names should be caught early.
•Learning curve — How quickly can the team become productive? NSubstitute's natural syntax is faster to learn than Moq's lambda expressions.
•Team familiarity — Is the team experienced with a particular framework's style? Migrating from Mockito to ts-mockito is easier than learning a completely different paradigm.
•Community and maintenance — Is the framework actively maintained? Is there good documentation and community support? Mockito, Jest, and Moq all have excellent communities.
•Performance — For large test suites, mock creation overhead can matter. Most mainstream frameworks have negligible overhead.
•Special needs — Do you need to mock statics, final classes, or perform other 'power' mocking? Most teams should avoid this, but legacy code may require it.

Recommended Defaults by Language
Language	Recommended Framework	Alternative	Why
Java	Mockito	Spock (if using Groovy)	De facto standard, excellent ecosystem
JavaScript	Jest built-in	Vitest (for Vite projects)	Zero config, comprehensive
TypeScript	Jest + ts-mockito	Vitest	Type safety + familiar Jest API
Python	unittest.mock	pytest-mock (with pytest)	Standard library, no dependencies
C#	Moq or NSubstitute	FakeItEasy	Mature, well-supported
Go	testify/mock	mockery	Standard approach for interfaces

Start Simple

When in doubt, choose the most popular framework for your language. The extensive documentation, Stack Overflow answers, and team familiarity outweigh marginal ergonomic differences. You can always switch later if specific needs arise.

Summary: Mocking Frameworks

We've surveyed the landscape of mocking frameworks across major languages. Let's consolidate the key insights:

Key Takeaways

•Frameworks provide essential capabilities — Auto-generation, stubbing, verification, argument matching, and spy functionality make testing practical at scale.
•Each language has a dominant framework — Mockito (Java), Jest (JS), unittest.mock (Python), Moq/NSubstitute (C#). Start with these.
•Type safety varies — TypeScript projects should prefer type-safe frameworks like ts-mockito. Python projects should use spec= or autospec.
•Loose mocking is the modern default — Strict record-replay style is mostly obsolete. Verify what matters, not every interaction.
•Power mocking is a design smell — If you need to mock statics, constructors, or private methods, refactor the code instead.
•Framework choice is secondary — All major frameworks are capable. Team familiarity and ecosystem integration matter more than features.

What's next:

Knowing which frameworks exist is only the beginning. The next page explores how to use mocking effectively—the best practices that separate productive mocking from tests that become maintenance burdens. We'll examine when to mock, what to mock, and how to keep tests maintainable.

Page Complete

You now have a comprehensive understanding of the mocking framework ecosystem. You can select appropriate tools for your language and project, and understand the tradeoffs between different approaches. Next, we'll explore the best practices that make mocking a sustainable part of your testing strategy.