本文探讨单元测试中是否应使用mock替代ioc容器获取依赖，以及集成测试为何应避免mock——核心在于明确测试目标：单元测试聚焦逻辑隔离，需mock外部依赖；集成测试验证组件协作，应使用真实依赖。
本文探讨单元测试中是否应使用mock替代ioc容器获取依赖，以及集成测试为何应避免mock——核心在于明确测试目标：单元测试聚焦逻辑隔离，需mock外部依赖；集成测试验证组件协作，应使用真实依赖。
在编写高质量测试时，正确处理被测类的依赖是关键决策点。你的两种实践——self::getContainer()->get(...) 与手动构造带 createMock() 的实例——分别对应两类测试范式，其选择不应凭习惯，而应由测试意图驱动。
✅ 单元测试：优先 Mock，确保快速、可靠、可重复
当测试目标是验证某个方法内部逻辑（如条件分支、数据转换、异常路径）且不关心依赖的真实行为时，必须使用 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)
);
}✅ 优势：
- 零外部依赖：无需启动 Redis、数据库或远程服务；
- 可控性高：可精确设定 Mock 的返回值、调用次数甚至抛出异常；
- 执行极快：毫秒级完成，适合 CI/CD 频繁运行；
- 失败定位准：失败必源于被测代码逻辑，而非基础设施问题。
⚠️ 注意：Mock 仅应覆盖真正影响测试目标的依赖。若某依赖（如 ParameterBagInterface）仅用于读取配置且行为稳定，也可用轻量真实对象（如 new ParameterBag(['key' => 'value'])），比 Mock 更简洁。
? 集成测试：禁用 Mock，启用真实协作链
集成测试的目标是验证多个组件（如 Service + Repository + Client）在真实环境下的协同是否符合预期。此时必须从 IOC 容器中获取完整依赖树：
protected function setUp(): void
{
parent::setUp();
$this->delayReportService = self::getContainer()->get(DelayReportService::class);
// 容器会自动注入真实 Redis 客户端、数据库 Repository 等
}✅ 正确做法：
- 使用测试专用配置（如
test/doctrine.yaml启用内存 SQLite）； - 启动轻量级测试服务（如
redis-server --port 6380）； - 利用 Symfony 的
WebTestCase或KernelTestCase加载完整容器。
❌ 避免在集成测试中 Mock 关键协作层（如 Repository、HTTP Client），否则将退化为“伪集成”，失去验证端到端流程的意义。
⚖️ 混合策略：按依赖类型分级处理（进阶推荐）
并非所有依赖都需同等对待。可采用分层策略提升测试效率与真实性平衡：
| 依赖类型 | 推荐方式 | 理由 |
|---|---|---|
| 外部系统（Redis、DB、HTTP API） | Mock（单元） / 真实轻量实例（集成） | 避免环境强耦合 |
内部领域服务（如 OrderCalculator） |
真实实例（即使手动 new） | 行为确定、无副作用、易维护 |
配置/工具类（ParameterBag, LoggerInterface） |
真实轻量对象或 Stub | 简化且不失真 |
示例混合写法：
protected function setUp(): void
{
parent::setUp();
$this->delayReportService = new DelayReportService(
$this->createMock(RedisQueueStorageClientInterface::class), // 外部系统 → Mock
new InMemoryOrderRepository(), // 内部仓储 → 真实轻量实现
$this->createMock(DelayReportRepository::class), // 可选 Mock（若复杂）
new FakeEstimatedArrivalTimeClient(), // 外部 API → Fake 实现
new ParameterBag(['retry_delay' => 5]) // 配置 → 真实对象
);
}总结：以测试契约定义技术选型
- 单元测试 = 逻辑契约 → Mock 所有非被测逻辑，保证隔离性；
- 集成测试 = 协作契约 → 使用真实依赖（配合测试环境），暴露集成缺陷；
- 永远问自己：“如果这个依赖挂了，我的测试是否应该失败？” 若答案是否定的，它就必须被 Mock 或替换。
最终，没有“绝对最佳实践”，只有“最匹配当前测试目标的实践”。清晰界定测试类型，并据此统一团队规范，才是工程健壮性的基石。
