PHP实现PHPSpec测试规范详解

PHPSpec 是一款专为行为驱动开发（BDD）设计的 PHP 测试工具，它彻底颠覆传统测试思维——不是为已有代码写测试，而是先用自然语义的规范（如 `it_should_add_two_numbers()`）描述类应具备的行为，再由工具自动生成类骨架和方法，强制开发者从接口契约出发、坚持构造注入、拥抱严格约定；它用 `shouldReturn()`、`shouldThrow()` 等可读性强的断言替代 `assert`，拒绝 setter 注入与运行时动态依赖，也天然规避数据库和 HTTP 等外部副作用——但这也意味着，一旦偏离“描述→生成→实现”的闭环节奏，或忽视命名空间、类型提示、自动加载等细节约定，就极易陷入报错困境；想真正释放 PHPSpec 的威力，你得愿意先放下实现冲动，让代码被行为所定义。

PHPSpec 是什么，它和 PHPUnit 有什么根本区别

PHPSpec 不是“写测试用例来验证已有代码”，而是用行为描述驱动开发：你先写一个 spec（规范文件），描述某个类“应该做什么”，PHPSpec 就会自动帮你生成待实现的类骨架。它强制你从接口/契约出发，而不是从实现细节出发。

• 它基于 BDD（行为驱动开发），核心单位是 it_should_do_something() 这样的方法名
• 不依赖 assert 断言，而是靠 shouldReturn()、shouldThrow()、shouldBe() 等语义化断言
• 默认不支持数据提供器（@dataProvider），也不直接运行 setUp() —— 初始化逻辑写在 let() 或 letGo() 里
• 生成的类默认是 final，且所有方法默认 public；若需 protected 或继承，得手动改

如果你已经写好了类再补 PHPSpec，大概率会卡在“类已存在但 spec 找不到对应方法”或“Method not found”错误上——这不是 bug，是它在提醒你：“你没按它的节奏来”。

初始化 spec 并让 PHPSpec 自动生成类和方法

PHPSpec 只有在“目标类尚不存在”时才真正发挥价值。比如你想做一个 Calculator 类，带一个 add() 方法：

• 运行：phpspec describe "App\Calculator"
• 它会在 spec/App/CalculatorSpec.php 生成骨架，并提示你运行 phpspec run
• 第一次执行 phpspec run，它会问你是否创建 App\Calculator —— 输入 y，它就生成空类到 src/App/Calculator.php

接着在 spec 中写行为：

function it_should_add_two_numbers()
{
    $this->add(2, 3)->shouldReturn(5);
}

再跑 phpspec run，它会报错说 add() 方法不存在，然后再次询问是否生成 —— 输入 y，它就往 Calculator 里加这个方法（含类型提示和返回声明）。

• 注意：参数类型必须显式写，否则 PHPSpec 无法推断签名，会跳过生成
• 如果用了 PHP 8.0+ 的联合类型（如 int|float），PHPSpec 7.x 会报错，建议降级到 int|float 拆成两个 spec，或升级到 PHPSpec 8（仍处于 alpha）
• shouldThrow() 要求异常类已存在，否则生成失败；可先 phpspec describe "App\Exception\InvalidInputException" 预建

spec 中怎么模拟依赖、处理构造注入

PHPSpec 对依赖注入的支持很“原教旨”：它默认只接受构造函数注入，且所有依赖必须是接口或具体类（不能是字符串别名）。例如：

function let(SomeService $service)
{
    $this->beConstructedWith($service);
}

• let() 是每个 spec 示例前的初始化钩子，参数名即依赖名，PHPSpec 自动 mock 它（除非你手动 new）
• 如果依赖本身也要被 spec 描述，先 phpspec describe "App\SomeService"，再在当前 spec 的 let() 中引用
• 不要试图在 let() 里调 $this->setSomething() —— PHPSpec 不鼓励 setter 注入；真需要，得在 beConstructedThrough() 中指定工厂方法
• Mock 行为用 $service->doSomething()->willReturn('ok')，但注意：它只对 public 方法生效；protected/private 方法无法 stub，得重构为组合或提取接口

运行失败时常见报错及应对

Class "App\Calculator" is not autoloadable：composer autoloader 没覆盖 src/，检查 composer.json 的 "autoload": {"psr-4": {"App\": "src/"}} 是否存在，并运行 composer dump-autoload

Call to undefined method ...::shouldReturn()：通常是用了 $this->method()->shouldReturn()，但该方法返回 void；PHPSpec 要求被链式调用的方法必须有返回值（哪怕是 $this）

Could not reflect class ... because: Class ... does not exist：spec 文件命名或命名空间和实际路径不一致，比如 spec 命名为 CalculatorSpec.php，但类名写成了 class MathCalculatorSpec —— 必须严格匹配 XXXSpec 且命名空间与目录结构一致

ArgumentCountError 在 beConstructedWith() 中出现：传参个数或类型与构造函数签名不符，PHPSpec 不做类型松散适配，少一个参数或类型不兼容都会崩

PHPSpec 的“顺手”建立在严格遵循它的约定之上。一旦脱离描述→生成→实现→再描述这个闭环，它就容易变成阻力而非助力。最常被忽略的一点是：它不处理数据库、HTTP 或外部 IO —— 那些必须抽象成接口，再由 spec 去描述接口行为，而不是去测 Guzzle 或 PDO。

终于介绍完啦！小伙伴们，这篇关于《PHP实现PHPSpec测试规范详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！