说实话， 作为一个在PHP圈子里摸爬滚打多年的开发者，我以前对“单元测试”这三个字是嗤之以鼻的。那时候的想法很简单：我代码写得这么溜，功能跑一遍没问题不就行了？写测试用例不仅浪费时间，还得维护，简直是给自己找罪受。直到有一天 我在凌晨三点主要原因是修改了一个看似无关紧要的通用方法，导致整个商城模块下单崩溃，看着报错日志欲哭无泪时我才意识到：没有测试的代码，就像是在裸奔，别纠结...。

特别是对于使用 ThinkPHP 框架的项目， 业务逻辑往往比较厚重，控制器和模型纠缠不清。如果不引入单元测试，项目越往后维护越像是在拆炸弹。今天我们就来聊聊 ThinkPHP5使用单元测试的方法 ThinkPHP5提供了便捷的单元测试支持,使得开发者能够轻松地对应用程序进行测试。

一、 环境准备：工欲善其事，必先利其器

在开始敲代码之前，我们得先把地基打好。单元测试在PHP领域，PHPUnit绝对是当之无愧的老大。 我始终觉得... 我们要把它集成到我们的ThinkPHP项目中。

先说说确保你已经安装了 PHP 和 Composer。这应该是现代PHP开发者的标配了如果你还没装，那赶紧去装一个，别耽误时间。然后在项目根目录下运行以下命令来安装 PHPUnit 和其他必要的依赖：，请大家务必...

composer require --dev phpunit/phpunit ^9.0

这将在你的项目中安装 PHPUnit 版本。注意这里用了 --dev 这是非常明智的做法，主要原因是测试工具通常只需要在开发环境使用，部署到生产环境时完全可以不带，这样能稍微减轻一点点生产环境的负担，太扎心了。。

在 Ubuntu 下为 ThinkPHP 项目进行单元测试，你可以遵循以下步骤。其实不管你是用Windows、 Mac还是Linux，只要Composer能跑，流程都大同小异，无非就是命令行路径的区别罢了，我CPU干烧了。。

二、 配置文件：给测试定个规矩

呃... 装好了库，接下来得告诉PHPUnit怎么去跑我们的测试。这时候就需要一个配置文件。在项目根目录下创建一个名为 phpunit.xml 的文件。这个文件将包含 PHPUnit 的配置信息。 ./application/test ./application/controller ./application/model 这个配置文件指定了测试文件的位置，以及需要被测试的文件类型。你看， 这里面的 bootstrap 属性指向了 vendor/autoload.php这是关键，它帮我们自动加载了所有类，不然你得在每个测试文件里手动include，那简直是噩梦，一针见血。。 那个 testsuites 节点定义了测试套件，我们告诉PHPUnit去 ./application/test 目录下找后缀为 Test.php 的文件。而 filter 部分则是为了代码覆盖率报告服务的， 它告诉PHPUnit只关注 application 目录下的控制器和模型，忽略掉其他的杂七杂八的文件。 三、 第一个测试用例：Hello World 戳到痛处了。 配置好了是不是手痒了？我们来写一个最简单的测试，确保环境没问题。在 ./application/test 目录下创建一个新的 PHP 文件，比方说 ExampleTest.php。在这个文件中， 编写一个简单的测试用例： assertTrue; } } 看着这段代码，你可能会说：“这不就是个废话吗？断言true等于true？” 别急，这就像是你买新车后的第一次试驾，虽然只是在门口转了一圈，但至少证明车能发动，轮子能转。如果这个都跑不通，那说明你的PHPUnit安装或者配置有问题，赶紧回头检查，蚌埠住了！。 四、 运行测试：见证奇迹的时刻 写好了测试，怎么跑呢？打开你的终端，进入到项目根目录。 我直接起飞。 在项目根目录下运行以下命令来施行测试： vendor/bin/phpunit 这将运行你在 phpunit.xml 文件中配置的测试套件。如果一切顺利，你应该能看到终端里输出绿色的字样， 捡漏。 那种感觉，怎么说呢，比吃了一顿火锅还舒服。 PHPUnit 将显示测试后来啊，包括、失败的测试以及失败的原因。如果不幸失败了 它会用红色的字狠狠地嘲讽你，并告诉你哪一行代码出了问题，期望值是什么实际值又是什么。这时候别急着改代码，先看看是不是测试逻辑写错了毕竟测试代码也是代码，也是会有Bug的。 五、 深入ThinkPHP：测试控制器和模型 光跑通 true 可不行，我们得来点真格的。ThinkPHP是一个MVC框架，我们最关心的就是控制器和模型。但是 Web环境下的测试比较麻烦，主要原因是涉及到HTTP请求、Response响应、Session、Cookie等等。 这时候，我们就需要用到一些技巧了。比如测试一个API接口，我们不想真的启动浏览器去访问，而是想在代码里模拟一个HTTP请求。虽然ThinkPHP 5自带了一些测试辅助类，但有时候我们还是得自己动手丰衣足食。 假设我们有一个用户注册的接口，我们需要测试它。这时候我们可能需要模拟 Request 对象，甚至可能需要用到 Mock对象来隔离数据库。是的，你没听错，真正的单元测试是不应该依赖真实数据库的， 总体来看... 主要原因是数据库太慢了而且数据状态难以控制。但在国内的实际开发中，为了图省事，很多人还是会连接测试数据库。这虽然不够纯粹，但至少比没测试强。 常用断言方法一览 在编写测试时你会用到各种各样的断言方法。为了方便查阅， 我整理了一个表格，这些都是你以后会经常打交道的“朋友”：，不忍直视。 断言方法 描述 使用场景举例 assertTrue 判断是否为 true 检查某个条件是否成立，比如验证用户是否登录。 assertEquals 判断 $a 是否等于 $b 最常用的， 比如检查计算后来啊是否正确，接口返回的JSON数据中某个字段是否匹配。 assertContains 判断 $haystack 是否包含 $needle 检查返回的数组里是否包含某个特定的ID，或者字符串里是否包含关键词。 assertCount 判断数组元素个数是否为 $n 比如分页查询，检查返回的数据条数是否符合预期。 assertInternalType 判断变量类型 确保接口返回的数据类型是正确的，防止前端主要原因是类型不对报错。 六、 进阶之路：如何写出高质量的测试 学会了怎么跑测试，只是万里长征走完了第一步。真正难的是如何写出“好”的测试。什么是好的测试？ 因为你对项目的了解加深，你可以为更多的控制器、模型和其他组件编写测试用例。只需确保遵循良好的测试实践， 躺平。 比方说编写可读性强的测试代码、覆盖各种边界情况等。 这里有几个我踩过坑出来的经验： 别测第三方库： 如果是Composer下载的包，假设它是没问题的。别去测Laravel或者ThinkPHP的核心代码，那是人家的事，你测好你自己的逻辑就行。 一个测试只测一件事： 别把一大堆逻辑塞进一个 test 方法里。如果一个方法挂了你要能立刻知道是哪块业务出了问题，而不是面对一堆报错发呆。 测试命名要清晰： testUserRegister 比 test1 好一万倍。当你几个月后回来看代码，或者同事接手你的代码时他们会感谢你的。 关注边界情况： 正常流程通常都没问题，容易出Bug的是边界。比如传个空字符串、传个负数、传个超长的字符串，看看系统会不会崩。这往往是发现深层次Bug的最佳途径。 七、 ：心态的转变 学习ThinkPHP单元测试，不仅仅是学习怎么用PHPUnit这个工具，更是一种编程思维的转变。 简单来说... 它强迫你把代码写得更模块化、更解耦，主要原因是如果你的代码耦合度太高，你就根本没法写测试。 刚开始写测试的时候， 你可能会觉得效率变低了毕竟写一行业务代码可能要写两三行测试代码。但是 当你重构代码、添加新功能，或者半夜被叫起来修Bug时看着那一排排绿色的测试通过条， 官宣。 你会感谢现在努力的自己。这是一种平安感，一种“我有底气，我不怕改坏东西”的自信。 无语了... 所以 别犹豫了打开你的编辑器，从第一个 assertTrue 开始，踏上你的ThinkPHP单元测试之旅吧。虽然过程可能会有点枯燥，甚至有点抓狂，但终点绝对是风景独好。