2、依赖隔离原则

为什么需要隔离依赖

在软件测试中，依赖隔离是指将被测单元与其外部依赖（数据库、网络服务、文件系统、第三方API等）解耦，使测试能够独立运行。没有依赖隔离，测试将面临以下问题：

• 测试不稳定：外部服务不可用或网络波动导致测试随机失败。
• 测试速度慢：每次测试都需建立真实数据库连接或发起HTTP请求。
• 测试环境复杂：需要搭建完整的依赖环境，增加CI/CD维护成本。
• 难以覆盖边界场景：真实依赖难以模拟超时、异常、空返回等极端情况。
• 测试与实现耦合：依赖的具体实现变更时，测试代码必须同步修改。

依赖注入与可测试性设计

依赖注入（Dependency Injection, DI）是实现依赖隔离的核心设计模式。它将依赖的创建与使用分离，由外部容器或调用方将依赖对象注入到被测对象中，而非由被测对象自行创建。

以下是一个典型的依赖注入代码示例，展示如何通过构造函数注入实现可测试性：

// 不可测试的版本：硬编码依赖
public class OrderService {
    private PaymentGateway paymentGateway;

    public OrderService() {
        // 内部创建具体实现，无法替换
        this.paymentGateway = new AlipayGateway();
    }

    public boolean processOrder(Order order) {
        return paymentGateway.charge(order.getAmount());
    }
}

// 可测试的版本：依赖注入
public class OrderService {
    private PaymentGateway paymentGateway;

    // 通过构造函数注入依赖
    public OrderService(PaymentGateway paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public boolean processOrder(Order order) {
        return paymentGateway.charge(order.getAmount());
    }
}

// 测试代码：注入 Mock 依赖
public class OrderServiceTest {
    @Test
    public void testProcessOrder_Success() {
        PaymentGateway mockGateway = Mockito.mock(PaymentGateway.class);
        when(mockGateway.charge(anyDouble())).thenReturn(true);

        OrderService service = new OrderService(mockGateway);
        Order order = new Order(100.0);

        assertTrue(service.processOrder(order));
        verify(mockGateway).charge(100.0);
    }
}

接口抽象与解耦

接口抽象是依赖隔离的基石。通过定义抽象接口，将"做什么"与"怎么做"分离，使得被测单元只依赖接口契约，而非具体实现。这样，在测试时就可以用 Mock 对象替换真实实现。

接口抽象带来的核心收益：

• 契约优先：接口定义了依赖的行为边界，测试基于契约编写，不受实现细节影响。
• 多态替换：同一接口可以有多种实现（生产实现、测试 Mock、Stub、Fake），切换成本极低。
• 演进友好：接口稳定后，实现可以独立优化、重构，不影响调用方和测试代码。

接口抽象的设计步骤：

1. 识别依赖边界：找出被测单元需要的外部服务（数据库、缓存、消息队列、第三方API等）。
2. 定义接口契约：为每个外部依赖定义接口，包含方法签名、参数、返回值、异常声明。
3. 实现生产代码：编写实现类，注入真实依赖（如数据库连接、HTTP客户端）。
4. 实现测试替身：为测试创建 Mock、Stub 或 Fake 实现，控制依赖行为。
5. 通过 DI 注入：在测试中注入测试替身，在生产代码中注入真实实现。

依赖隔离的层次结构

在实际项目中，依赖隔离通常分为三个层次，每个层次对应不同的隔离策略：