企业官网建设流程全解析

• 示例工程
• 数据库
• 教程
• 后端

Mockery 是 PHP 生态中简洁而灵活的 mock 对象框架，用于在 PHPUnit、PHPSpec 等测试框架中构建测试替身。本文以官方文档 installation.rst 为骨架，结合本仓库中 Laravel 示例项目的真实配置，系统讲解 Composer、PEAR、Git 三种安装方式、版本约束选择与 Hamcrest 依赖关系。读完本文，你将能在自己的 Laravel / PHP 项目中正确安装 Mockery，并理解其在测试栈中的实际作用。

Mockery 在当前仓库中的定位

本仓库的 samples/development-frameworks/laravel 是一个基于 Laravel 5.1 的 ToDo 示例应用（其 composer.json 中require声明了laravel/framework: 5.1.*）。Mockery 以开发依赖的形式出现在该项目的require-dev段：

"require-dev": { "fzaninotto/faker": "~1.4", "mockery/mockery": "0.9.*", "phpunit/phpunit": "~4.0", "phpspec/phpspec": "~2.1" }

可以看到项目锁定的 Mockery 版本约束为0.9.*，这与 vendor 内 Mockery 源码的 composer.json 中dev-master别名0.9.x-dev的设定一致，说明该示例项目使用的正是 0.9 系列版本。

在require-dev中声明依赖意味着：Mockery 只服务于开发与测试环节，不会进入生产环境部署——这正是官方安装文档强调的"development dependency"语义。项目的测试代码位于 tests 目录（TestCase.php、HomeTest.php、SignInTest.php、TodoTest.php），配合 PHPUnit 与 Laravel 内置的 Testing API 使用。

方式一：通过 Composer 安装（推荐）

官方文档将 Composer 作为首选安装方式。整个流程分三步：

第 1 步：为项目安装 Composer。这是 PHP 项目的依赖管理基础工具，安装完成后即可在项目目录下使用php composer.phar或全局composer命令。

第 2 步：在composer.json中声明 Mockery 为开发依赖。官方文档给出的建议配置如下：

{ "require-dev": { "mockery/mockery": "dev-master" } }

这里存在一个关键的版本选择问题。dev-master指向 Mockery 源码仓库的 master 分支，即开发版本。官方文档明确提示：虽然项目会尽力保持 master 分支稳定，但如果希望使用当前稳定版本，应改用@stable标签。实践中更常见的做法是指定明确的版本区间，例如本仓库 Laravel 示例项目使用的"mockery/mockery": "0.9.*"，它会解析到 0.9 系列的最新稳定版。

第 3 步：执行依赖更新命令。

php composer.phar update

update会依据composer.json的约束解析并安装依赖，同时生成composer.lock锁定精确版本，保证团队与 CI 环境的一致性。官方文档特别提醒：由于 Mockery 被声明在require-dev段，生产环境执行php composer.phar update --no-dev时它不会被安装，从而避免把测试依赖带入线上。

安装完成后，vendor 目录中的 mockery/mockery 便包含了完整的库结构：library/Mockery下的Container.php、Mock.php、Expectation.php、MockInterface.php等核心类文件，以及docs、examples、tests等子目录，library/通过 PSR-0 规则（"Mockery": "library/"）完成自动加载。

方式二：通过 PEAR 安装

在 Composer 普及之前，PEAR 是 PHP 扩展与库的经典分发渠道。Mockery 曾托管在survivethedeepend.com的 PEAR channel 上，官方文档给出的安装命令如下：

sudo pear channel-discover pear.survivethedeepend.com sudo pear channel-discover hamcrest.googlecode.com/svn/pear sudo pear install --alldeps deepend/Mockery

两个channel-discover分别注册 Mockery 自身与 Hamcrest 的 PEAR 源，--alldeps参数则要求一并安装所有依赖。从 Mockery 的 composer.json 可以看到其运行环境要求为php >=5.3.2且依赖lib-pcre >=7.0，安装前需确保环境满足这些条件。

需要说明的是，PEAR 属于 Mockery 早期的分发渠道，随着 Composer 成为 PHP 事实上的依赖管理标准，现在绝大多数项目（包括本仓库的 Laravel 示例）都采用 Composer 方式，PEAR 命令可视为历史兼容方案参考。

方式三：通过 Git 克隆安装

Mockery 的 Git 仓库以 master 分支承载开发版本。官方文档给出两种用法：

• 结合 Composer：如方式一所示，在composer.json中以dev-master引用开发版即可；
• 结合 PEAR：直接克隆源码后通过package.xml安装：

git clone git://github.com/padraic/mockery.git cd mockery sudo pear channel-discover hamcrest.googlecode.com/svn/pear sudo pear install --alldeps package.xml

这种方式适合需要跟踪最新开发成果、或希望直接阅读/修改 Mockery 源码的开发者。

不可或缺的搭档：Hamcrest

官方文档在三种安装方式之后特别强调了 Hamcrest 的地位："上述过程会同时安装 Mockery 与 Hamcrest。省略 Hamcrest 不会破坏 Mockery，但推荐安装它，因为 Hamcrest 为参数匹配（argument matching）提供了更丰富的功能。"

这一点在源码层面得到了印证：Mockery 的 composer.json 的require段声明了"hamcrest/hamcrest-php": "~1.1"，说明在当前仓库所携带的 0.9 版本中，Hamcrest 已经是硬性依赖，随 Composer 安装会自动拉取。它提供的匹配器（Matcher）能力对应library/Mockery/Matcher目录中的实现，用于在shouldReceive()->with(...)等场景中编写更精确、更可读的参数断言。

版本升级与行为变更（0.8 / 0.9）

对于升级场景，官方 upgrading.rst 记录了两次重要的行为变化：

• 升级到 0.9：mock 生成器（generator）被完全重写，任何对 Mockery 内部深度集成的代码都需要重新评估；
• 升级到 0.8：shouldIgnoreMissing()在方法调用不匹配任何已知预期时，返回值从\Mockery\Undefined实例改为null。如需恢复 0.7.2 的行为，可以显式调用asUndefined()：

$mock = \Mockery::mock('stdClass')->shouldIgnoreMissing()->asUndefined();

由于本仓库 Laravel 示例锁定的是0.9.*，使用时应以上述 0.9 语义为准。

在 Laravel 示例项目中的实际使用形态

虽然 SignInTest.php 等测试代码主要通过 Laravel 内置的 Testing API（visit、click、actingAs、factory等）编写，Mockery 在该测试栈中扮演的是底层测试替身支撑的角色——Laravel 5.1 的测试基础设施依赖 Mockery 来处理 Facade、事件与容器绑定的 mock 需求。这也解释了为何示例项目的 composer.json 将mockery/mockery列为require-dev。

Mockery 的核心 DSL 用法可以参考官方 simple_example.rst：通过\Mockery::mock()创建替身，用shouldReceive()->times(3)->andReturn(...)声明预期调用与返回值，并在tearDown()中调用m::close()清理容器。该文档还指出，接入 PHPUnit 集成后可省去手动tearDown()。

验证安装是否成功

安装完成后，可进入项目根目录执行测试来验证整个测试栈（含 Mockery）是否就绪：

vendor/bin/phpunit

该命令由 Mockery 的 README 推荐，适用于任何已通过 Composer 安装 Mockery 的项目。如果看到测试全部通过，说明 Mockery 及其 Hamcrest 依赖已被正确解析、自动加载并可被测试框架正常调用。

• 示例工程
• 数据库
• 教程
• 后端