PHPUnit是可配置可扩展的质量保障体系，关键在合理配置phpunit.xml（如backupGlobals="false"）、审慎解读覆盖率、避免Mock滥用、优化CI执行效率。
PHPUnit 不是“跑通测试就行”的工具，它是一套可配置、可扩展的质量保障体系。真正卡住团队的，从来不是写不出第一个 assertEquals，而是覆盖率虚高、Mock 泛滥、测试变慢、CI 里频繁飘红却找不到根因。
PHPUnit 配置文件里哪些选项真会影响测试稳定性
很多人把 phpunit.xml 当成模板复制粘贴，但几个关键开关不调，测试就容易在 CI 或不同环境里行为不一致：
-
backupGlobals="false"是必须的——开启它会让每个测试用例重置全局变量，但代价是显著拖慢执行速度；多数现代 PHP 代码已无强依赖全局状态，关掉更稳更快 -
beStrictAboutTestsThatDoNotTestAnything="true"能揪出空测试方法或只调用未断言的代码，避免“看似跑过实则没测” -
convertDeprecationsToExceptions="true"在 PHP 8.4+ 环境下尤其关键：把E_DEPRECATED当异常抛出，防止旧写法（如create_function）在开发机不报错、上线后崩溃 - 别忽略
extensions块：如果用了phpstan或psalm的自定义规则，需显式声明加载，否则覆盖率报告和静态分析会脱节
覆盖率报告里红色代码段到底该不该补测试
生成 vendor/bin/phpunit --coverage-html build/coverage 后看到红色行，第一反应不是“赶紧加 test”，而是先问三个问题：
- 这行是不是
throw new \Exception(...)或exit()这类防御性兜底？这类代码本就不该被常规路径触发，强行 mock 路径反而让测试脆弱 - 是否属于 setter/getter、DTO 属性赋值、或日志打点等纯副作用逻辑？覆盖率工具会标记它们，但 TDD 原则下，这类代码不应成为测试目标
- 是否在
catch块里处理了极低概率异常（如网络超时、磁盘满）？真实模拟成本高，可用expectException()+ 人工构造异常对象覆盖主干，不必追求 100% - 核心业务逻辑分支（如支付状态机中的
if ($order->isPaid() && !$order->isShipped())）必须覆盖，且要验证不同组合下的输出，不能只测true && true
Mock 对象用多了，测试反而更难维护
Mock 是隔离依赖的利器，但滥用会导致测试与实现细节强耦合，一改代码全红：
立即学习“PHP免费学习笔记（深入）”；
- 优先用真实轻量对象：比如测试一个依赖
LoggerInterface的服务，直接传入new NullLogger()比 mock 接口更简单、更稳定 - 慎 mock 第三方 SDK：像
Stripe\Charge::create()这类，应封装为自己的PaymentGateway接口，再 mock 这个接口；否则 SDK 升级时，mock 断言全失效 - 避免 mock 返回值链式调用：如
$mock->getOrder()->getUser()->getName()，这种 mock 本质是在测试框架行为而非业务逻辑；应重构为接受User对象入参，或使用willReturnOnConsecutiveCalls()控制返回序列 - 所有 mock 必须配
expects($this->once())或类似约束，否则“调没调”“调几次”都成黑盒，掩盖真实调用路径问题
CI 中 PHPUnit 执行慢，90% 出在三件事上
本地秒过、CI 跑 5 分钟还超时？重点查这三项：
- SQLite 内存数据库没配对：测试中用
sqlite::memory:是快，但若在setUp()里反复exec("CREATE TABLE...")，每次新建连接都重建 schema；应统一在setUpBeforeClass()里建一次，或用DatabaseTestCase类做事务回滚 - Xdebug 开着跑覆盖率：CI 里生成 HTML 报告时默认启用 Xdebug，但 Xdebug 会拖慢执行 3–5 倍；正确做法是 CI 分两轮：第一轮
phpunit快速验功能，第二轮phpunit --coverage-clover单独跑覆盖率（且仅限主干分支） - 测试类没按层级拆分：把
UserTest、OrderTest、PaymentTest全塞进一个大文件，PHPUnit 加载解析耗时剧增；严格按tests/Unit/User/目录结构组织，配合phpunit.xml中的<testsuites>显式指定路径
覆盖率数字本身没有意义，有意义的是你清楚哪几行没覆盖、为什么没覆盖、以及敢不敢为它承担线上风险。TDD 的终点不是绿色进度条，而是每次改代码时，你心里那句“这个分支我测过了”。
