PHP Mock 对象生成

wen PHP项目 2026-08-11 2

PHP单元测试进阶：精通Mock对象生成，告别脆弱测试的5大实战策略

目录导读

什么是Mock对象？为什么你的测试离不开它？
PHP Mock对象生成的三大主流方案（PHPUnit原生 / Mockery / Prophecy）
实战对比：三种方案在复杂场景下的代码差异
Mock对象生成的5个致命陷阱与规避指南
从生成到设计：Mock驱动的测试重构思维
高频问答：关于Mock对象，你纠结的那些事儿

在PHP开发中,单元测试的目标是隔离并验证单一类或方法的行为，现实代码往往充斥着数据库连接、外部API调用、文件系统操作等依赖，如果测试直接触碰这些真实依赖，不仅速度慢，而且结果不稳定。Mock对象（模拟对象）便成为测试的“替身演员”，它能在不执行真实逻辑的前提下，预设返回值和验证调用次数，从而让测试既快又准。

PHP Mock 对象生成

但很多开发者对Mock的理解停留在“createMock()一下就行”的阶段，导致写出的测试要么过于耦合实现细节，要么在重构时一碰就碎，本文将基于搜索引擎中关于PHP Mock的最佳实践，去伪存真，为你提炼一套可落地的生成与使用策略。

什么是Mock对象？为什么你的测试离不开它？

Mock对象是测试替身的一种,它动态生成一个实现了指定接口或继承指定类的对象，并在测试中替换真实依赖，核心价值在于：

隔离外部副作用：不真正写数据库、不发HTTP请求。
控制行为：指定方法返回固定值（willReturn）或抛出异常（willThrowException）。
验证交互：断言某个方法是否被调用，以及调用参数（expects($this->once())）。

没有Mock,单元测试就会退化为集成测试，一旦依赖服务宕机，你的测试也跟着“红”，这违背了单元测试的初衷。

PHP Mock对象生成的三大主流方案

目前生态中最常用的三种工具,各有千秋：

方案	典型API风格	优势	适用场景
PHPUnit原生	`$this->createMock(ClassName::class)`	零依赖，随框架分发	简单返回值和基础验证
Mockery	`Mockery::mock(ClassName::class)`	链式API极优雅，支持鸭子类型	复杂参数约束、部分Mock（`makePartial`）
Prophecy	`$this->prophesize(ClassName::class)`	先预言后揭示，更符合BDD风格	Symfony项目默认集成，对复杂回调友好

实战对比：三种方案在复杂场景下的代码差异

假设我们需要Mock一个UserRepository接口，要求findById(1)返回一个用户对象，且该方法只能被调用一次。

PHPUnit原生写法：

$repo = $this->createMock(UserRepository::class);
$repo->expects($this->once())
     ->method('findById')
     ->with(1)
     ->willReturn(new User(1, 'Alice'));

Mockery写法：

$repo = Mockery::mock(UserRepository::class);
$repo->shouldReceive('findById')
     ->once()
     ->with(1)
     ->andReturn(new User(1, 'Alice'));

Prophecy写法：

$repo = $this->prophesize(UserRepository::class);
$repo->findById(1)->shouldBeCalledTimes(1)->willReturn(new User(1, 'Alice'));
$repo = $repo->reveal();

从可读性看,Mockery的andReturn和Prophecy的willReturn都更接近自然语言，但注意，PHPUnit原生的expects()虽然啰嗦，但IDE自动补全支持最好。

Mock对象生成的5个致命陷阱与规避指南

陷阱1：Mock了不该Mock的类（如值对象），值对象（如Money、DateTime）是有状态且无副作用的，应直接使用真实实例。
陷阱2：过度指定参数，用with()匹配具体值会导致测试脆弱，改用withCallback()或Mockery::on()做宽松匹配。
陷阱3：忽略final类和方法，PHPUnit无法Mock final方法，此时要么解耦设计，要么使用Mockery的mock('alias:Class')（但需谨慎）。
陷阱4：忘了清理Mockery，在tearDown()中必须调用Mockery::close()，否则测试间会相互污染。
陷阱5：只验证调用次数，不验证参数，只写expects($this->once())而不写->with()，等于形同虚设。

从生成到设计：Mock驱动的测试重构思维

Mock对象不是万能的,它的存在是倒逼你改善设计的信号，如果某个类需要大量Mock才能测，往往意味着它违反了依赖倒置原则，经典重构路径：

提取接口（如PaymentGatewayInterface），让业务类依赖接口而非具体实现。
使用构造器注入，避免在类内部new依赖，这样Mock才能“塞进去”。
对于静态方法或单例,考虑引入门面模式（Facade） 或服务容器，降低Mock难度。

好的Mock是接口契约的体现，而不是对实现步骤的逐条记录。

高频问答：关于Mock对象，你纠结的那些事儿

Q1：Mock和Stub有什么区别？ A：Stub只提供预设返回值（willReturn），而Mock除了提供返回值，还能验证行为（expects），Mock是Stub的超集，日常测试中，80%的场景其实只需要Stub。

Q2：Mockery可以替代PHPUnit自带的Mock吗？ A：可以，但没必要完全替换，PHPUnit自带Mock足够处理简单场景，Mockery在复杂参数匹配（如\Closure、数组子集匹配）上更灵活，混合使用没毛病，只要保持团队规范统一。

Q3：Mock出来的对象，能调用真实方法吗？ A：默认不行，但Mockery支持makePartial()，允许保留原对象的部分方法逻辑，仅覆盖指定方法，这在修复遗留代码时非常有用。

Q4：为什么我的Mock不管用？总报“Method is not mocked”？ A：大概率你Mock的是final类、私有方法，或者你调用的是类中不存在的方法，请检查类定义和方法可见性，另一个常见原因是：你在setUp()里创建Mock，但在测试方法里重新new了一个新对象传入，导致Mock没生效。

Q5：Mock对象性能有影响吗？ A：生成Mock本身开销很小（微秒级），真正的性能瓶颈在于每个测试用例都要重新生成一遍，可以通过@covers注解缩小分析范围，或者使用测试套件级别的依赖注入容器来复用部分轻量Mock。

通过上述策略,你不仅能生成高效的Mock对象，还能反过来审视自己的代码架构，Mock的目标是让测试描述行为，而非实现细节，当你发现测试因为“换了一种排序方式”就崩了，说明你的Mock指定得太死板——放宽约束，让测试关注结果而非过程，这才是PHP单元测试的终极奥义。

（完）