如何正确编写依赖外部服务的单元测试

在单元测试中，应聚焦于被测类自身的逻辑行为，而非其依赖服务的内部实现；对 ServiceA 的测试需覆盖 ServiceB 方法返回 true、false 和抛出异常三种场景，以验证其调用链的健壮性与正确性。

在单元测试中，应聚焦于被测类自身的逻辑行为，而非其依赖服务的内部实现；对 ServiceA 的测试需覆盖 ServiceB 方法返回 true、false 和抛出异常三种场景，以验证其调用链的健壮性与正确性。

当 ServiceA 调用 ServiceB.shouldVerify() 仅获取一个布尔值，并将其透传给下游服务（无条件分支或业务判断），看似逻辑简单，但这恰恰是单元测试的关键覆盖点——因为 ServiceA 的行为正确性高度依赖于它如何响应 ServiceB 的各种输出状态。

✅ 正确做法：在 ServiceA 的单元测试中，使用 Mock 框架（如 Mockito）隔离 ServiceB，并显式验证以下三种核心场景：

• 当 serviceB.shouldVerify(...) 返回 true 时，ServiceA.foo() 是否按预期执行后续流程（如调用 serviceC.process(true)）；
• 当返回 false 时，是否触发对应路径（如记录日志、跳过某操作）；
• 当 serviceB.shouldVerify(...) 抛出异常（如 RuntimeException 或自定义 ServiceUnavailableException）时，ServiceA.foo() 是否能妥善捕获、处理或传播异常，避免崩溃或数据不一致。

示例（JUnit 5 + Mockito）：

@ExtendWith(MockitoExtension.class)
class ServiceATest {

    @Mock
    private ServiceB serviceB;

    @InjectMocks
    private ServiceA serviceA;

    @Test
    void foo_shouldProcessWhenServiceBReturnsTrue() {
        // given
        when(serviceB.shouldVerify(any())).thenReturn(true);

        // when
        serviceA.foo();

        // then
        verify(serviceC).process(true); // 假设后续调用 serviceC.process(value)
    }

    @Test
    void foo_shouldHandleFalseResponse() {
        when(serviceB.shouldVerify(any())).thenReturn(false);
        serviceA.foo();
        verify(serviceC).process(false);
    }

    @Test
    void foo_shouldPropagateServiceBException() {
        when(serviceB.shouldVerify(any())).thenThrow(new RuntimeException("Timeout"));

        assertThatThrownBy(() -> serviceA.foo())
            .isInstanceOf(RuntimeException.class)
            .hasMessage("Timeout");
    }
}

⚠️ 注意事项：

• ❌ 不要试图在 ServiceA 测试中“验证 ServiceB 的逻辑是否正确”——那是 ServiceB 自身测试的责任；
• ✅ 必须验证 ServiceA 对依赖调用的契约使用是否合规：参数是否正确传递？异常是否被合理处理？返回值是否被如实流转？
• ? 若 ServiceA.foo() 中存在隐式逻辑（如根据 value 决定是否调用某个补偿服务），即使当前代码未体现，也应在测试中预留断言扩展点，提升可维护性。

总结：单元测试的本质是保障被测类在可控边界内的行为确定性。ServiceA 虽不包含复杂业务规则，但它作为服务编排层，承担着连接、转换与容错职责。对其开展多态响应测试（true/false/exception），是构建高可靠性微服务架构不可或缺的一环。