6a:T521,// ❌ UNTESTABLE: Direct dependencies make isolation impossible class PaymentProcessor { private paymentGateway: StripeGateway; private logger: FileLogger; private auditService: DatabaseAuditService; constructor() { // Direct instantiation creates hard dependencies this.paymentGateway = new StripeGateway( process.env.STRIPE_API_KEY! ); this.logger = new FileLogger('/var/log/payments.log'); this.auditService = new DatabaseAuditService( new PostgresConnection(process.env.DB_URL!) ); } async processPayment(amount: number, cardToken: string): Promise { this.logger.info(`Processing payment of ${amount}`); try { // Real Stripe API call - can't test without actual Stripe account const result = await this.paymentGateway.charge(amount, cardToken); // Real database write - can't test without database await this.auditService.recordTransaction(result); this.logger.info(`Payment successful: ${result.transactionId}`); return result; } catch (error) { this.logger.error(`Payment failed: ${error.message}`); throw error; } } }6b:T46e,# ❌ UNTESTABLE: Direct dependencies make isolation impossible class PaymentProcessor: def __init__(self): # Direct instantiation creates hard dependencies self._payment_gateway = StripeGateway( api_key=os.environ['STRIPE_API_KEY'] ) self._logger = FileLogger('/var/log/payments.log') self._audit_service = DatabaseAuditService( PostgresConnection(os.environ['DB_URL']) ) def process_payment(self, amount: float, card_token: str) -> PaymentResult: self._logger.info(f"Processing payment of {amount}") try: # Real Stripe API call - can't test without actual Stripe account result = self._payment_gateway.charge(amount, card_token) # Real database write - can't test without database self._audit_service.record_transaction(result) self._logger.info(f"Payment successful: {result.transaction_id}") return result except Exception as error: self._logger.error(f"Payment failed: {str(error)}") raise6c:T5a7,// ❌ UNTESTABLE: Direct dependencies make isolation impossible public class PaymentProcessor { private final StripeGateway paymentGateway; private final FileLogger logger; private final DatabaseAuditService auditService; public PaymentProcessor() { // Direct instantiation creates hard dependencies this.paymentGateway = new StripeGateway( System.getenv("STRIPE_API_KEY") ); this.logger = new FileLogger("/var/log/payments.log"); this.auditService = new DatabaseAuditService( new PostgresConnection(System.getenv("DB_URL")) ); } public PaymentResult processPayment(double amount, String cardToken) throws PaymentException { logger.info(String.format("Processing payment of %f", amount)); try { // Real Stripe API call - can't test without actual Stripe account PaymentResult result = paymentGateway.charge(amount, cardToken); // Real database write - can't test without database auditService.recordTransaction(result); logger.info(String.format("Payment successful: %s", result.getTransactionId())); return result; } catch (Exception e) { logger.error(String.format("Payment failed: %s", e.getMessage())); throw new PaymentException(e); } } }6d:T65e,// ✅ TESTABLE: DIP-compliant design with dependency injection // Step 1: Define abstractions (interfaces) interface PaymentGateway { charge(amount: number, cardToken: string): Promise; } interface Logger { info(message: string): void; error(message: string): void; } interface AuditService { recordTransaction(result: PaymentResult): Promise; } // Step 2: Accept dependencies through constructor // Step 3: Program to interfaces, not implementations class PaymentProcessor { constructor( private readonly paymentGateway: PaymentGateway, // Abstraction private readonly logger: Logger, // Abstraction private readonly auditService: AuditService // Abstraction ) {} async processPayment( amount: number, cardToken: string ): Promise { this.logger.info(`Processing payment of ${amount}`); try { const result = await this.paymentGateway.charge(amount, cardToken); await this.auditService.recordTransaction(result); this.logger.info(`Payment successful: ${result.transactionId}`); return result; } catch (error) { this.logger.error(`Payment failed: ${error.message}`); throw error; } } } // Production configuration (composition root) const productionProcessor = new PaymentProcessor( new StripeGateway(process.env.STRIPE_API_KEY!), new FileLogger('/var/log/payments.log'), new DatabaseAuditService(new PostgresConnection(process.env.DB_URL!)) );6e:T6a3,# ✅ TESTABLE: DIP-compliant design with dependency injection from abc import ABC, abstractmethod from dataclasses import dataclass # Step 1: Define abstractions (abstract base classes / protocols) class PaymentGateway(ABC): @abstractmethod def charge(self, amount: float, card_token: str) -> PaymentResult: pass class Logger(ABC): @abstractmethod def info(self, message: str) -> None: pass @abstractmethod def error(self, message: str) -> None: pass class AuditService(ABC): @abstractmethod def record_transaction(self, result: PaymentResult) -> None: pass # Step 2 & 3: Accept abstractions through constructor @dataclass class PaymentProcessor: payment_gateway: PaymentGateway # Abstraction logger: Logger # Abstraction audit_service: AuditService # Abstraction def process_payment(self, amount: float, card_token: str) -> PaymentResult: self.logger.info(f"Processing payment of {amount}") try: result = self.payment_gateway.charge(amount, card_token) self.audit_service.record_transaction(result) self.logger.info(f"Payment successful: {result.transaction_id}") return result except Exception as error: self.logger.error(f"Payment failed: {str(error)}") raise # Production configuration (composition root) production_processor = PaymentProcessor( payment_gateway=StripeGateway(os.environ['STRIPE_API_KEY']), logger=FileLogger('/var/log/payments.log'), audit_service=DatabaseAuditService( PostgresConnection(os.environ['DB_URL']) ) )6f:T7a0,// ✅ TESTABLE: DIP-compliant design with dependency injection // Step 1: Define abstractions (interfaces) public interface PaymentGateway { PaymentResult charge(double amount, String cardToken) throws PaymentException; } public interface Logger { void info(String message); void error(String message); } public interface AuditService { void recordTransaction(PaymentResult result) throws AuditException; } // Step 2 & 3: Accept abstractions through constructor public class PaymentProcessor { private final PaymentGateway paymentGateway; // Abstraction private final Logger logger; // Abstraction private final AuditService auditService; // Abstraction public PaymentProcessor( PaymentGateway paymentGateway, Logger logger, AuditService auditService) { this.paymentGateway = paymentGateway; this.logger = logger; this.auditService = auditService; } public PaymentResult processPayment(double amount, String cardToken) throws PaymentException { logger.info(String.format("Processing payment of %f", amount)); try { PaymentResult result = paymentGateway.charge(amount, cardToken); auditService.recordTransaction(result); logger.info(String.format("Payment successful: %s", result.getTransactionId())); return result; } catch (Exception e) { logger.error(String.format("Payment failed: %s", e.getMessage())); throw new PaymentException(e); } } } // Production configuration (composition root) PaymentProcessor productionProcessor = new PaymentProcessor( new StripeGateway(System.getenv("STRIPE_API_KEY")), new FileLogger("/var/log/payments.log"), new DatabaseAuditService( new PostgresConnection(System.getenv("DB_URL"))) );70:T1495,// ✅ Complete test suite with mock injection import { describe, it, expect, vi, beforeEach } from 'vitest'; // Mock implementations for testing class MockPaymentGateway implements PaymentGateway { private chargeResult: PaymentResult | null = null; private shouldFail: boolean = false; private failureError: Error | null = null; // Configuration methods for test setup setChargeResult(result: PaymentResult): void { this.chargeResult = result; } setFailure(error: Error): void { this.shouldFail = true; this.failureError = error; } async charge(amount: number, cardToken: string): Promise { if (this.shouldFail) { throw this.failureError!; } return this.chargeResult!; } } class MockLogger implements Logger { infoMessages: string[] = []; errorMessages: string[] = []; info(message: string): void { this.infoMessages.push(message); } error(message: string): void { this.errorMessages.push(message); } // Test helper reset(): void { this.infoMessages = []; this.errorMessages = []; } } class MockAuditService implements AuditService { recordedTransactions: PaymentResult[] = []; async recordTransaction(result: PaymentResult): Promise { this.recordedTransactions.push(result); } } describe('PaymentProcessor', () => { let mockGateway: MockPaymentGateway; let mockLogger: MockLogger; let mockAudit: MockAuditService; let processor: PaymentProcessor; beforeEach(() => { // Fresh mocks for each test - complete isolation mockGateway = new MockPaymentGateway(); mockLogger = new MockLogger(); mockAudit = new MockAuditService(); // Inject mocks instead of real dependencies processor = new PaymentProcessor(mockGateway, mockLogger, mockAudit); }); describe('successful payment processing', () => { it('should return payment result from gateway', async () => { // Arrange: Configure mock behavior const expectedResult: PaymentResult = { transactionId: 'txn_123', amount: 100, status: 'success', }; mockGateway.setChargeResult(expectedResult); // Act: Execute the unit under test const result = await processor.processPayment(100, 'tok_visa'); // Assert: Verify the result expect(result).toEqual(expectedResult); }); it('should record successful transaction in audit service', async () => { const expectedResult: PaymentResult = { transactionId: 'txn_456', amount: 250, status: 'success', }; mockGateway.setChargeResult(expectedResult); await processor.processPayment(250, 'tok_mastercard'); // Verify interaction with dependency expect(mockAudit.recordedTransactions).toHaveLength(1); expect(mockAudit.recordedTransactions[0]).toEqual(expectedResult); }); it('should log processing start and success', async () => { const result: PaymentResult = { transactionId: 'txn_789', amount: 500, status: 'success', }; mockGateway.setChargeResult(result); await processor.processPayment(500, 'tok_amex'); expect(mockLogger.infoMessages).toHaveLength(2); expect(mockLogger.infoMessages[0]).toContain('Processing payment of 500'); expect(mockLogger.infoMessages[1]).toContain('Payment successful: txn_789'); }); }); describe('failed payment processing', () => { it('should propagate gateway errors', async () => { // Arrange: Configure failure scenario const gatewayError = new Error('Card declined'); mockGateway.setFailure(gatewayError); // Act & Assert: Verify error propagation await expect( processor.processPayment(100, 'tok_declined') ).rejects.toThrow('Card declined'); }); it('should log error when payment fails', async () => { mockGateway.setFailure(new Error('Insufficient funds')); await expect( processor.processPayment(100, 'tok_insufficient') ).rejects.toThrow(); expect(mockLogger.errorMessages).toHaveLength(1); expect(mockLogger.errorMessages[0]).toContain('Payment failed'); }); it('should not record failed transactions', async () => { mockGateway.setFailure(new Error('Network error')); await expect( processor.processPayment(100, 'tok_error') ).rejects.toThrow(); // Audit service should not be called on failure expect(mockAudit.recordedTransactions).toHaveLength(0); }); }); });71:T11ee,# ✅ Complete test suite with mock injection import pytest from typing import Optional from dataclasses import dataclass, field # Mock implementations for testing class MockPaymentGateway(PaymentGateway): def __init__(self): self._charge_result: Optional[PaymentResult] = None self._should_fail: bool = False self._failure_error: Optional[Exception] = None def set_charge_result(self, result: PaymentResult) -> None: self._charge_result = result def set_failure(self, error: Exception) -> None: self._should_fail = True self._failure_error = error def charge(self, amount: float, card_token: str) -> PaymentResult: if self._should_fail: raise self._failure_error return self._charge_result class MockLogger(Logger): def __init__(self): self.info_messages: list[str] = [] self.error_messages: list[str] = [] def info(self, message: str) -> None: self.info_messages.append(message) def error(self, message: str) -> None: self.error_messages.append(message) def reset(self) -> None: self.info_messages = [] self.error_messages = [] class MockAuditService(AuditService): def __init__(self): self.recorded_transactions: list[PaymentResult] = [] def record_transaction(self, result: PaymentResult) -> None: self.recorded_transactions.append(result) @pytest.fixture def mock_gateway(): return MockPaymentGateway() @pytest.fixture def mock_logger(): return MockLogger() @pytest.fixture def mock_audit(): return MockAuditService() @pytest.fixture def processor(mock_gateway, mock_logger, mock_audit): # Inject mocks instead of real dependencies return PaymentProcessor( payment_gateway=mock_gateway, logger=mock_logger, audit_service=mock_audit ) class TestSuccessfulPaymentProcessing: def test_returns_payment_result_from_gateway( self, processor, mock_gateway ): # Arrange expected_result = PaymentResult( transaction_id='txn_123', amount=100.0, status='success' ) mock_gateway.set_charge_result(expected_result) # Act result = processor.process_payment(100.0, 'tok_visa') # Assert assert result == expected_result def test_records_successful_transaction( self, processor, mock_gateway, mock_audit ): expected_result = PaymentResult( transaction_id='txn_456', amount=250.0, status='success' ) mock_gateway.set_charge_result(expected_result) processor.process_payment(250.0, 'tok_mastercard') assert len(mock_audit.recorded_transactions) == 1 assert mock_audit.recorded_transactions[0] == expected_result def test_logs_processing_and_success( self, processor, mock_gateway, mock_logger ): result = PaymentResult( transaction_id='txn_789', amount=500.0, status='success' ) mock_gateway.set_charge_result(result) processor.process_payment(500.0, 'tok_amex') assert len(mock_logger.info_messages) == 2 assert 'Processing payment of 500' in mock_logger.info_messages[0] assert 'Payment successful: txn_789' in mock_logger.info_messages[1] class TestFailedPaymentProcessing: def test_propagates_gateway_errors(self, processor, mock_gateway): gateway_error = Exception('Card declined') mock_gateway.set_failure(gateway_error) with pytest.raises(Exception, match='Card declined'): processor.process_payment(100.0, 'tok_declined') def test_logs_error_when_payment_fails( self, processor, mock_gateway, mock_logger ): mock_gateway.set_failure(Exception('Insufficient funds')) with pytest.raises(Exception): processor.process_payment(100.0, 'tok_insufficient') assert len(mock_logger.error_messages) == 1 assert 'Payment failed' in mock_logger.error_messages[0] def test_does_not_record_failed_transactions( self, processor, mock_gateway, mock_audit ): mock_gateway.set_failure(Exception('Network error')) with pytest.raises(Exception): processor.process_payment(100.0, 'tok_error') assert len(mock_audit.recorded_transactions) == 072:T13f2,// ✅ Complete test suite with mock injection import org.junit.jupiter.api.*; import static org.junit.jupiter.api.Assertions.*; import java.util.ArrayList; import java.util.List; // Mock implementations for testing class MockPaymentGateway implements PaymentGateway { private PaymentResult chargeResult; private boolean shouldFail = false; private PaymentException failureException; public void setChargeResult(PaymentResult result) { this.chargeResult = result; } public void setFailure(PaymentException exception) { this.shouldFail = true; this.failureException = exception; } @Override public PaymentResult charge(double amount, String cardToken) throws PaymentException { if (shouldFail) { throw failureException; } return chargeResult; } } class MockLogger implements Logger { public final List infoMessages = new ArrayList<>(); public final List errorMessages = new ArrayList<>(); @Override public void info(String message) { infoMessages.add(message); } @Override public void error(String message) { errorMessages.add(message); } public void reset() { infoMessages.clear(); errorMessages.clear(); } } class MockAuditService implements AuditService { public final List recordedTransactions = new ArrayList<>(); @Override public void recordTransaction(PaymentResult result) { recordedTransactions.add(result); } } class PaymentProcessorTest { private MockPaymentGateway mockGateway; private MockLogger mockLogger; private MockAuditService mockAudit; private PaymentProcessor processor; @BeforeEach void setUp() { mockGateway = new MockPaymentGateway(); mockLogger = new MockLogger(); mockAudit = new MockAuditService(); // Inject mocks instead of real dependencies processor = new PaymentProcessor(mockGateway, mockLogger, mockAudit); } @Nested class SuccessfulPaymentProcessing { @Test void returnsPaymentResultFromGateway() throws PaymentException { PaymentResult expectedResult = new PaymentResult( "txn_123", 100.0, "success" ); mockGateway.setChargeResult(expectedResult); PaymentResult result = processor.processPayment(100.0, "tok_visa"); assertEquals(expectedResult, result); } @Test void recordsSuccessfulTransaction() throws PaymentException { PaymentResult expectedResult = new PaymentResult( "txn_456", 250.0, "success" ); mockGateway.setChargeResult(expectedResult); processor.processPayment(250.0, "tok_mastercard"); assertEquals(1, mockAudit.recordedTransactions.size()); assertEquals(expectedResult, mockAudit.recordedTransactions.get(0)); } @Test void logsProcessingAndSuccess() throws PaymentException { PaymentResult result = new PaymentResult( "txn_789", 500.0, "success" ); mockGateway.setChargeResult(result); processor.processPayment(500.0, "tok_amex"); assertEquals(2, mockLogger.infoMessages.size()); assertTrue(mockLogger.infoMessages.get(0) .contains("Processing payment of 500")); assertTrue(mockLogger.infoMessages.get(1) .contains("Payment successful: txn_789")); } } @Nested class FailedPaymentProcessing { @Test void propagatesGatewayErrors() { mockGateway.setFailure(new PaymentException("Card declined")); PaymentException thrown = assertThrows( PaymentException.class, () -> processor.processPayment(100.0, "tok_declined") ); assertTrue(thrown.getMessage().contains("Card declined")); } @Test void logsErrorWhenPaymentFails() { mockGateway.setFailure(new PaymentException("Insufficient funds")); assertThrows( PaymentException.class, () -> processor.processPayment(100.0, "tok_insufficient") ); assertEquals(1, mockLogger.errorMessages.size()); assertTrue(mockLogger.errorMessages.get(0) .contains("Payment failed")); } @Test void doesNotRecordFailedTransactions() { mockGateway.setFailure(new PaymentException("Network error")); assertThrows( PaymentException.class, () -> processor.processPayment(100.0, "tok_error") ); assertEquals(0, mockAudit.recordedTransactions.size()); } } }73:T7ba,// Using Vitest's mocking capabilities with DIP-compliant code import { describe, it, expect, vi, beforeEach, Mock } from 'vitest'; describe('PaymentProcessor with Framework Mocks', () => { let mockGateway: PaymentGateway; let mockLogger: Logger; let mockAudit: AuditService; let processor: PaymentProcessor; beforeEach(() => { // Create mocks using vi.fn() - still implements our interfaces mockGateway = { charge: vi.fn() }; mockLogger = { info: vi.fn(), error: vi.fn() }; mockAudit = { recordTransaction: vi.fn() }; processor = new PaymentProcessor(mockGateway, mockLogger, mockAudit); }); it('should call gateway with correct parameters', async () => { const expectedResult: PaymentResult = { transactionId: 'txn_test', amount: 150, status: 'success' }; // Configure mock behavior (mockGateway.charge as Mock).mockResolvedValue(expectedResult); await processor.processPayment(150, 'tok_test'); // Verify interaction expect(mockGateway.charge).toHaveBeenCalledWith(150, 'tok_test'); expect(mockGateway.charge).toHaveBeenCalledTimes(1); }); it('should verify logging sequence', async () => { (mockGateway.charge as Mock).mockResolvedValue({ transactionId: 'txn_seq', amount: 200, status: 'success' }); await processor.processPayment(200, 'tok_seq'); // Verify call order expect(mockLogger.info).toHaveBeenNthCalledWith( 1, expect.stringContaining('Processing payment of 200') ); expect(mockLogger.info).toHaveBeenNthCalledWith( 2, expect.stringContaining('Payment successful') ); }); });74:T62b,# Using pytest-mock with DIP-compliant code import pytest from unittest.mock import Mock, AsyncMock @pytest.fixture def mock_gateway(mocker): return mocker.Mock(spec=PaymentGateway) @pytest.fixture def mock_logger(mocker): return mocker.Mock(spec=Logger) @pytest.fixture def mock_audit(mocker): return mocker.Mock(spec=AuditService) @pytest.fixture def processor(mock_gateway, mock_logger, mock_audit): return PaymentProcessor( payment_gateway=mock_gateway, logger=mock_logger, audit_service=mock_audit ) class TestWithFrameworkMocks: def test_calls_gateway_with_correct_parameters( self, processor, mock_gateway ): expected_result = PaymentResult( transaction_id='txn_test', amount=150.0, status='success' ) mock_gateway.charge.return_value = expected_result processor.process_payment(150.0, 'tok_test') # Verify interaction mock_gateway.charge.assert_called_once_with(150.0, 'tok_test') def test_verifies_logging_sequence( self, processor, mock_gateway, mock_logger ): mock_gateway.charge.return_value = PaymentResult( transaction_id='txn_seq', amount=200.0, status='success' ) processor.process_payment(200.0, 'tok_seq') # Verify call order calls = mock_logger.info.call_args_list assert 'Processing payment of 200' in str(calls[0]) assert 'Payment successful' in str(calls[1])62:{"json":{"id":"seed_eee50ae53971b9e9a4bff320c1795a13","slug":"dip-and-testability","category":"Low-Level Design","topic":"DIP and Testability","title":"DIP and Testability","description":"Master the profound connection between the Dependency Inversion Principle and software testability. Learn how DIP enables mock injection, unit isolation, testable architecture design, and comprehensive test infrastructure—transforming testing from an afterthought into a first-class architectural concern.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_740ce6f9866a9c7189c438b0e2a79695","title":"Mock Injection Through DIP","order":0,"content":[{"id":"opening-hook","title":"The Testing Revelation","content":[{"data":{"content":"Software testing is one of the most critical disciplines in professional software development, yet many engineers struggle with a fundamental question: **Why are some codebases easy to test while others seem virtually untestable?** The answer lies not in testing frameworks or mocking libraries, but in a principle we've been studying: the **Dependency Inversion Principle (DIP)**.\n\nWhen you understand the deep connection between DIP and testability, you'll realize that testable code isn't an accident or a luxury—it's a **natural consequence of principled design**. Conversely, code that's hard to test is almost always code that violates DIP. This page explores the most immediate benefit of DIP compliance: the ability to inject mock dependencies, enabling true unit testing."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand how DIP enables mock injection, why direct dependencies make testing difficult, the mechanics of substituting test doubles through abstraction, and patterns for designing injectable dependencies that make testing seamless and natural.","variant":"info"},"type":"callout"}]},{"id":"problem-direct-dependencies","title":"The Problem of Direct Dependencies","content":[{"data":{"content":"Before we can appreciate how DIP enables mock injection, we must first understand what makes testing difficult in its absence. The root cause of untestable code is almost always **direct dependencies**—when a class creates or directly references concrete implementations rather than depending on abstractions.\n\nConsider a seemingly simple class that processes payments:"},"type":"text"},{"data":{"fileName":"DirectDependencyProblem","languages":[{"code":"$6a","label":"TypeScript","value":"typescript"},{"code":"$6b","label":"Python","value":"python"},{"code":"$6c","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**Attempting to test this code reveals multiple insurmountable problems:**"},"type":"text"},{"data":{"items":["**External Service Coupling** — Testing requires a real Stripe account with valid credentials. Each test costs real money, runs slowly due to network latency, and may fail due to external service issues completely unrelated to your code.","**Infrastructure Requirements** — Tests need a real PostgreSQL database running and properly configured. This creates environment complexity, slows down test execution, and introduces flakiness from database state.","**File System Dependencies** — The file logger writes to `/var/log/payments.log`. Tests either need write permissions to this location or will fail with permission errors—assuming the path even exists in the test environment.","**Environment Variables** — Tests require specific environment variables to be set. Missing or incorrect values cause cryptic failures that have nothing to do with the logic being tested.","**State Pollution** — Each test run leaves artifacts: files on disk, records in the database, possibly charges on the Stripe account. Tests affect each other and the external world unpredictably.","**Isolation Impossibility** — You cannot test `processPayment` in isolation. Every test exercises the entire stack: Stripe API, database, file system—all intertwined with the business logic you're trying to verify."],"title":{"icon":"XCircle","text":"Testing Roadblocks from Direct Dependencies","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Fundamental Violation","content":"This code violates DIP at its core: a high-level module (PaymentProcessor containing business logic) directly depends on low-level modules (StripeGateway, FileLogger, DatabaseAuditService—concrete implementations). The high-level module creates its own dependencies, making it impossible to substitute alternatives for testing.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"understanding-mock-injection","title":"Understanding Mock Injection","content":[{"data":{"content":"**Mock injection** is the technique of replacing real dependencies with test doubles (mocks, stubs, fakes) during testing. This allows you to:\n\n1. **Isolate** the unit under test from external systems\n2. **Control** the behavior of dependencies precisely\n3. **Verify** interactions between the unit and its collaborators\n4. **Simulate** edge cases that are difficult or impossible to reproduce with real systems\n\nFor mock injection to work, the code must be **designed to accept dependencies from the outside** rather than creating them internally. This is precisely what DIP enables."},"type":"text"},{"data":{"rows":[["**Dummy**","Fill parameter lists","Does nothing, may throw if called","When a dependency is required but not used in the specific test path"],["**Stub**","Provide canned answers","Returns pre-configured values","When you need to simulate specific responses from dependencies"],["**Spy**","Record interactions","Wraps real object, recording calls","When you need to verify interactions while using real behavior"],["**Mock**","Verify expectations","Pre-programmed with expected calls","When you need to verify specific methods were called with specific arguments"],["**Fake**","Working implementation","Simplified but functional alternative","When you need realistic behavior without external dependencies (e.g., in-memory database)"]],"caption":"Types of Test Doubles","headers":["Test Double","Purpose","Behavior","Use Case"]},"type":"table"},{"data":{"content":"**The critical insight:** All these test doubles work by **substituting for real dependencies**. But substitution is only possible when the code under test **depends on abstractions rather than concretions**. This is DIP in action—the principle exists precisely to enable this kind of substitutability."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The DIP-Testing Connection","content":"DIP isn't just an academic principle—it's the **engineering prerequisite for testable design**. When you follow DIP, mock injection becomes trivial. When you violate DIP, mock injection becomes impossible without reflection hacks or invasive testing frameworks that break encapsulation.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"dip-enabled-testable-design","title":"DIP-Enabled Testable Design","content":[{"data":{"content":"Let's transform the untestable `PaymentProcessor` into a properly designed, DIP-compliant version. The transformation requires three steps:\n\n1. **Define abstractions** for each dependency\n2. **Accept dependencies through the constructor** (dependency injection)\n3. **Program to interfaces**, not implementations\n\nHere's the refactored, testable version:"},"type":"text"},{"data":{"fileName":"DIPCompliantDesign","languages":[{"code":"$6d","label":"TypeScript","value":"typescript"},{"code":"$6e","label":"Python","value":"python"},{"code":"$6f","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**Critical observations about this design:**"},"type":"text"},{"data":{"items":["**Abstractions are owned by the high-level module** — The `PaymentGateway`, `Logger`, and `AuditService` interfaces are defined based on what `PaymentProcessor` needs, not based on what Stripe or PostgreSQL provides.","**No knowledge of concrete implementations** — `PaymentProcessor` has no imports or references to `StripeGateway`, `FileLogger`, or `DatabaseAuditService`. It only knows about abstractions.","**Dependencies flow inward** — `StripeGateway` implements `PaymentGateway` (depends on the abstraction). The high-level module doesn't depend on the low-level module; the low-level module depends on abstractions defined by the high-level module.","**Construction is separated from use** — `PaymentProcessor` uses its dependencies but doesn't create them. Creation happens in a 'composition root' that wires everything together."],"title":{"icon":"CheckCircle","text":"DIP Compliance Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":3},{"id":"implementing-mock-injection","title":"Implementing Mock Injection","content":[{"data":{"content":"With the DIP-compliant design, mock injection becomes trivial. We can create test doubles that implement the same interfaces and inject them into `PaymentProcessor`. Here are complete, production-quality test examples:"},"type":"text"},{"data":{"fileName":"MockInjectionTests","languages":[{"code":"$70","label":"TypeScript","value":"typescript"},{"code":"$71","label":"Python","value":"python"},{"code":"$72","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"**Key observations about these tests:**"},"type":"text"},{"data":{"items":["**Complete isolation** — No network calls, no database connections, no file system access. Tests run in milliseconds.","**Full control** — We precisely configure how mocks behave, enabling testing of any scenario including edge cases and error conditions.","**Interaction verification** — We can verify exactly how the unit interacts with its dependencies (what was logged, what was audited).","**Deterministic** — Tests always produce the same results because there are no external variables.","**Fast feedback** — The entire test suite runs in under a second, enabling continuous testing during development."],"title":{"icon":"Sparkles","text":"Characteristics of DIP-Enabled Tests","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":4},{"id":"mock-injection-patterns","title":"Mock Injection Patterns","content":[{"data":{"content":"There are several patterns for implementing mock injection, each with distinct tradeoffs. Understanding these patterns helps you choose the right approach for your testing context."},"type":"text"},{"data":{"tabs":[{"id":"constructor","badge":"Preferred","label":"Constructor Injection","content":[{"data":{"content":"**Constructor injection** is the gold standard for mock injection. Dependencies are provided through the constructor, making them explicit and immutable."},"type":"text"},{"data":{"languages":[{"code":"// ✅ Constructor Injection - Dependencies are explicit and immutable\nclass OrderService {\n constructor(\n private readonly repository: OrderRepository,\n private readonly paymentService: PaymentService,\n private readonly notificationService: NotificationService\n ) {}\n \n async placeOrder(order: Order): Promise {\n // Use injected dependencies\n await this.paymentService.process(order.payment);\n const savedOrder = await this.repository.save(order);\n await this.notificationService.sendConfirmation(savedOrder);\n return new OrderConfirmation(savedOrder);\n }\n}\n\n// Test: Simply pass mocks through constructor\nconst service = new OrderService(mockRepo, mockPayment, mockNotification);","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"items":["✅ **Explicit dependencies** — All dependencies are visible in the constructor signature","✅ **Immutable** — Dependencies cannot be changed after construction","✅ **Compile-time safety** — Missing dependencies cause compilation/instantiation errors","✅ **Simple testing** — Just pass mocks to the constructor"],"variant":"glass"},"type":"list"}],"titleIcon":"CheckCircle"},{"id":"setter","badge":"Use Carefully","label":"Setter Injection","content":[{"data":{"content":"**Setter injection** allows dependencies to be changed after construction. This can be useful for optional dependencies but introduces mutability concerns."},"type":"text"},{"data":{"languages":[{"code":"// ⚠️ Setter Injection - Useful for optional dependencies\nclass ReportGenerator {\n private formatter: ReportFormatter = new DefaultFormatter();\n private exporter: ReportExporter = new ConsoleExporter();\n \n // Setters allow overriding defaults\n setFormatter(formatter: ReportFormatter): void {\n this.formatter = formatter;\n }\n \n setExporter(exporter: ReportExporter): void {\n this.exporter = exporter;\n }\n \n generateReport(data: ReportData): void {\n const formatted = this.formatter.format(data);\n this.exporter.export(formatted);\n }\n}\n\n// Test: Override only what you need\nconst generator = new ReportGenerator();\ngenerator.setFormatter(mockFormatter); // Override just the formatter\ngenerator.generateReport(testData);","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"items":["✅ **Optional dependencies** — Good for dependencies with sensible defaults","✅ **Partial mocking** — Override only what you need for specific tests","⚠️ **Mutable state** — Object state can change unexpectedly","⚠️ **Temporal coupling** — Must call setters before using the object"],"variant":"glass"},"type":"list"}],"titleIcon":"AlertCircle"},{"id":"method","badge":"Situational","label":"Method Injection","content":[{"data":{"content":"**Method injection** passes dependencies as method parameters. This is useful when different invocations need different dependencies."},"type":"text"},{"data":{"languages":[{"code":"// ✅ Method Injection - When dependency varies per call\nclass DataProcessor {\n async processData(\n data: RawData,\n encoder: DataEncoder, // May vary per invocation\n validator: DataValidator // May vary per invocation\n ): Promise {\n const validated = await validator.validate(data);\n const encoded = await encoder.encode(validated);\n return { original: data, processed: encoded };\n }\n}\n\n// Test: Different tests can use different mock combinations\nconst processor = new DataProcessor();\n\n// Test with JSON encoding\nawait processor.processData(testData, mockJsonEncoder, mockValidator);\n\n// Test with XML encoding - same processor, different dependency\nawait processor.processData(testData, mockXmlEncoder, mockValidator);","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"items":["✅ **Per-call flexibility** — Different dependencies for each invocation","✅ **Explicit in call site** — Caller sees exactly what dependencies are used","⚠️ **Verbose** — Every call must provide all dependencies","⚠️ **Burdens caller** — Caller must obtain and manage dependencies"],"variant":"glass"},"type":"list"}],"titleIcon":"Info"}],"defaultTab":"constructor"},"type":"tabs"},{"data":{"icon":"Lightbulb","title":"Pattern Selection Guideline","content":"**Use constructor injection by default** for required dependencies. Use setter injection for truly optional dependencies with sensible defaults. Use method injection when the dependency legitimately varies per method call. Constructor injection is testable, explicit, and enables immutability—making it the right choice in the vast majority of cases.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"handwritten-vs-framework-mocks","title":"Hand-Written vs Framework Mocks","content":[{"data":{"content":"When implementing mock injection, you have a choice between hand-written mocks (as shown in previous examples) and mocking frameworks. Both approaches work with DIP-compliant code, but they have different characteristics."},"type":"text"},{"data":{"left":[{"data":{"items":["**Full control** — You implement exactly what you need","**Type safety** — Compile-time verification of interface compliance","**Readable** — Mock behavior is explicit in code","**Reusable** — Share mocks across test files","**Debuggable** — Easy to step through mock logic","**More setup code** — Must implement all interface methods"],"title":{"icon":"CheckCircle","text":"Hand-Written Mocks","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"right":[{"data":{"items":["**Less boilerplate** — Generate mocks automatically","**Dynamic configuration** — Change behavior per test easily","**Verification helpers** — Built-in interaction verification","**Auto-stubbing** — Default implementations provided","**Learning curve** — Framework-specific API to learn","**Magic behavior** — Can hide interface violations"],"title":{"icon":"Zap","text":"Mocking Frameworks","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"FrameworkMockExample","languages":[{"code":"$73","label":"TypeScript","value":"typescript"},{"code":"$74","label":"Python","value":"python"}]},"type":"code"},{"data":{"icon":"Info","title":"DIP Makes Both Approaches Viable","content":"Whether you use hand-written mocks or framework mocks, **DIP is what makes mock injection possible in the first place**. Without interfaces and constructor injection, neither approach would work without resorting to invasive techniques like reflection or monkey-patching.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Mock Injection Through DIP","content":[{"data":{"content":"We've explored the fundamental connection between the Dependency Inversion Principle and mock injection—the cornerstone of effective unit testing. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Direct dependencies create untestable code** — When classes create their own dependencies, you cannot substitute test doubles. Testing requires real databases, real APIs, and real file systems.","**DIP enables substitutability** — By depending on abstractions and accepting dependencies through injection, classes become open to having any implementation provided—including test doubles.","**Mock injection requires abstractions** — Whether using hand-written mocks or mocking frameworks, the mechanism only works when code depends on interfaces rather than concrete classes.","**Constructor injection is preferred** — It makes dependencies explicit, ensures immutability, and provides compile-time verification that all required dependencies are provided.","**Testable code is well-designed code** — The same structure that enables mock injection also provides flexibility for production use cases: swapping implementations, feature toggling, and runtime configuration."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nMock injection is just the beginning of DIP's impact on testability. In the next page, we'll explore **isolating units for testing**—how DIP enables you to test each component in complete isolation, verifying behavior without the complexity of integration. We'll examine the boundaries of unit testing, the role of test doubles in creating hermetic tests, and patterns for managing test complexity as systems grow."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand how DIP enables mock injection—the mechanism by which test doubles replace real dependencies during testing. This is the foundation of unit testing in object-oriented systems. Next, we'll explore how to achieve true unit isolation through DIP-compliant design.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_4f229236ea9c0038309f3257ef200425","title":"Isolating Units for Testing","order":1,"content":null,"isLocked":true},{"id":"seed_7a8066e52021ee5abab7962ad20eaa09","title":"Designing for Testability","order":2,"content":null,"isLocked":true},{"id":"seed_70ff04bdba0d6c6fed2204792ae5c030","title":"DIP in Test Architecture","order":3,"content":null,"isLocked":true}]}}