单元测试Mock非必要依赖及集成测试Mock使用的最佳实践咨询

场景说明 #

我在编写单元测试时，最初通过IOC容器获取DelayReportService实例：

protected function setUp(): void
{
    parent::setUp();
    $this->delayReportService = self::getContainer()->get(DelayReportService::class);
}

之后发现要测试的方法与类的依赖无关，于是改为Mock所有依赖后直接实例化服务：

protected function setUp(): void
{
    parent::setUp();
    $this->delayReportService = new DelayReportService(
        $this->createMock(RedisQueueStorageClientInterface::class),
        $this->createMock(OrderRepository::class),
        $this->createMock(DelayReportRepository::class),
        $this->createMock(EstimatedArrivalTimeClientInterface::class),
        $this->createMock(ParameterBagInterface::class)
    );
}

问题解答 #

1. 单元测试中无需依赖时Mock所有依赖是否为最佳实践？ #

这是单元测试的标准实践，理由如下：

• 单元测试的核心是隔离被测对象，只验证它自身的逻辑正确性。Mock所有依赖能确保测试结果仅由被测类的代码决定，不会被外部依赖的状态、实现细节干扰。
• 即使当前测试的方法暂时用不到某些依赖，Mock它们也能避免后续风险：比如后续代码修改导致该依赖被调用时，测试不会突然失败；同时保持测试代码的一致性，避免部分Mock部分不Mock的混乱。
• 可优化点：如果某些依赖在整个测试类中完全不会被调用，可以用更轻量的Stub（比如空实现）代替严格的Mock，减少不必要的配置，但Mock本身完全合规。

2. 集成测试中是否不应使用Mock？ #

集成测试的核心是验证多个组件协作的逻辑，所以不是绝对禁止使用Mock，但要谨慎：

• 核心依赖不能Mock：比如要测试DelayReportService与真实Redis、数据库的交互逻辑，必须使用真实的测试环境实例，否则无法验证集成后的正确性。
• 非核心/外部依赖可以Mock：如果依赖是第三方服务、外部API，存在调用成本高（付费、速率限制）或难以模拟异常场景的情况，可以Mock该外部依赖，专注于测试内部组件之间的集成逻辑。
• 总结原则：集成测试只Mock那些难以控制、非核心的外部依赖，核心的内部协作组件尽量用真实实例。

内容的提问来源于stack exchange，提问作者sina