7a:T531,// 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 { // 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.7b:T712,// ❌ BEFORE: Concrete dependency - Hard to test class PaymentProcessor { private gateway = new StripePaymentGateway(); // Hardcoded concrete class async process(amount: number): Promise { 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; } class PaymentProcessor { constructor(private gateway: IPaymentGateway) {} // Depends on abstraction async process(amount: number): Promise { 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 { 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); }); });7c:T47f,// 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(); 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?7d:T777,describe("OrderService", () => { // Testing the happy path it("should complete order when payment succeeds", async () => { const mockGateway = createMock(); 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(); 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(); 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(); 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"); }); });7e:T842,// ❌ 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"); }); });72:{"json":{"id":"seed_7f38bdd40e5272f319328a89d0817af0","slug":"mocking-dependencies","category":"System Design (LLD)","topic":"Mocking Dependencies","title":"Mocking Dependencies in Object-Oriented Testing","description":"Master the art and science of mocking dependencies in object-oriented testing. Learn why isolation is crucial for unit tests, understand the theoretical foundations of test doubles, explore mocking frameworks, and discover how to avoid common pitfalls that lead to brittle and meaningless tests.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_ce48dc5c4ed424b9d4d18bdb48adfc2b","title":"Why We Mock Dependencies","order":0,"content":[{"id":"opening-hook","title":"The Isolation Imperative","content":[{"data":{"content":"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.\n\n**This is the fundamental problem that mocking solves.**\n\nMocking 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."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"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.","variant":"info"},"type":"callout"}]},{"id":"problem-of-dependencies","title":"The Problem of External Dependencies","content":[{"data":{"content":"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:\n\n**External dependencies create testing challenges:**"},"type":"text"},{"data":{"items":["**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."],"title":{"icon":"AlertCircle","text":"Testing Challenges from Dependencies","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**The dependency graph explosion:**\n\nConsider 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.\n\nThis is not unit testing. This is integration testing wearing a unit test's clothing."},"type":"text"},{"data":{"code":"$7a","variant":"default","fileName":"dependency-complexity.ts","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Integration Testing vs Unit Testing","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"unit-testing-philosophy","title":"The Unit Testing Philosophy","content":[{"data":{"content":"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.\n\n**What makes a test a 'unit' test?**\n\nThe 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:\n\n> **A unit test exercises the smallest piece of testable software in isolation from other parts of the system.**\n\nThe 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."},"type":"text"},{"data":{"rows":[["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"]],"caption":"Characteristics of True Unit Tests","headers":["Characteristic","Isolated (Mocked Dependencies)","Non-Isolated (Real Dependencies)"]},"type":"table"},{"data":{"content":"**The FIRST principles of unit testing:**\n\nGood unit tests adhere to the FIRST principles, each of which is enabled by proper mocking:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"CheckCircle","text":"FIRST Principles","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"The Fast Feedback Loop","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"dependency-inversion","title":"Dependency Inversion and Testability","content":[{"data":{"content":"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.\n\nWhen 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.\n\n**Dependency Inversion enables mocking:**"},"type":"text"},{"data":{"left":[{"data":{"items":["PaymentProcessor creates new StripeGateway()","Cannot substitute test double","Must configure actual Stripe sandbox","Tests require network access","Tightly coupled to Stripe implementation"],"title":{"icon":"XCircle","text":"Concrete Dependencies (Hard to Mock)","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["PaymentProcessor receives IPaymentGateway","Test provides MockPaymentGateway","No external configuration needed","Tests run entirely in-memory","Loosely coupled to any gateway implementation"],"title":{"icon":"CheckCircle","text":"Abstract Dependencies (Easy to Mock)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"code":"$7b","variant":"default","fileName":"dependency-inversion.ts","showLineNumbers":true},"type":"code"},{"data":{"content":"**The seam concept:**\n\nMichael 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.\n\nCode with few seams is hard to test. Code with many seams—achieved through proper dependency inversion—is a pleasure to test."},"type":"text"},{"data":{"icon":"Info","title":"Testability as a Design Quality","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"what-mocking-means","title":"What Mocking Actually Means","content":[{"data":{"content":"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.\n\n**The taxonomy of test doubles:**\n\nGerard Meszaros, in *xUnit Test Patterns*, defines five types of test doubles. 'Mock' is just one:"},"type":"text"},{"data":{"rows":[["**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"]],"caption":"Test Double Taxonomy","headers":["Type","Purpose","Verification","Example Use Case"]},"type":"table"},{"data":{"content":"**The distinction between state and behavior verification:**\n\nThe fundamental difference between these doubles lies in how they verify correctness:\n\n- **State verification** checks the final state of the system after the action. *\"After calling processPayment(), is order.status equal to 'paid'?\"*\n\n- **Behavior verification** checks that certain interactions occurred. *\"Was paymentGateway.charge() called exactly once with $100?\"*\n\nMocks (in the strict sense) use behavior verification with pre-programmed expectations. Stubs and spies typically use state verification or post-hoc interaction checking."},"type":"text"},{"data":{"code":"$7c","variant":"default","fileName":"state-vs-behavior.ts","showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"When to Use Each","content":"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.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"benefits-of-mocking","title":"The Benefits of Mocking","content":[{"data":{"content":"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.\n\n**Primary benefits of mocking dependencies:**"},"type":"text"},{"data":{"items":["**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."],"title":{"icon":"CheckCircle","text":"Benefits of Proper Mocking","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"content":"**Enabling edge case testing:**\n\nPerhaps 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:"},"type":"text"},{"data":{"code":"$7d","variant":"default","fileName":"testing-edge-cases.ts","showLineNumbers":true},"type":"code"},{"data":{"icon":"CheckCircle","title":"Testing Failure Paths","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"mocking-as-design-feedback","title":"Mocking as Design Feedback","content":[{"data":{"content":"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.\n\n**Mocking difficulty signals design issues:**"},"type":"text"},{"data":{"rows":[["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"]],"caption":"Mocking Difficulties and Their Design Implications","headers":["Mocking Difficulty","Likely Design Problem","Suggested Refactoring"]},"type":"table"},{"data":{"content":"**The litmus test for good design:**\n\nIf 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.\n\nThis feedback loop is invaluable: it surfaces design problems during testing, when they're cheap to fix, rather than in production, when they're expensive."},"type":"text"},{"data":{"code":"$7e","variant":"default","fileName":"design-feedback.ts","showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"Listen to the Tests","content":"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.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"testing-pyramid","title":"The Testing Pyramid and Mocking","content":[{"data":{"content":"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.\n\n**The testing pyramid:**\n\nThe 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)."},"type":"text"},{"data":{"rows":[["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"]],"caption":"Testing Pyramid Layers","headers":["Layer","Speed","Isolation","Mocking Usage","What It Validates"]},"type":"table"},{"data":{"content":"**Why the pyramid shape matters:**\n\nThe pyramid is wide at the base (many unit tests) and narrow at the top (few E2E tests) because of the tradeoffs involved:\n\n- **Unit tests** are cheap, fast, and reliable. You can have thousands. They pinpoint failures precisely.\n- **E2E tests** are expensive, slow, and fragile. You should have few. They validate broad flows but localize failures poorly.\n\nMocking 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."},"type":"text"},{"data":{"items":["**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"],"title":{"icon":"Target","text":"Balanced Test Strategy","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Ice Cream Cone Anti-Pattern","content":"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.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-path-forward","title":"Summary: Why We Mock","content":[{"data":{"content":"We've established the philosophical and practical foundations for mocking dependencies. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**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."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow 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."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"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.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_d97c330c62597bac4ef40ddd35b408bd","title":"Mocking Frameworks Overview","order":1,"content":null,"isLocked":true},{"id":"seed_d6d76ce500c9b2a931a7e2c45e273cdb","title":"Mocking Best Practices","order":2,"content":null,"isLocked":true},{"id":"seed_1265bf40e3452a7eddb6269a912e033a","title":"Over-Mocking Pitfalls","order":3,"content":null,"isLocked":true}]}}