如何利用Composer管理项目中的单元测试依赖-composer-PHP中文网

phpunit必须装入require-dev而非require，否则生产环境会冗余安装、浪费资源并引发autoloader冲突；正确命令是composer require --dev phpunit/phpunit，误装后需先remove再重装。

如何利用composer管理项目中的单元测试依赖

PHPUnit 必须装进 require-dev，不能进 require；否则生产环境会多出无用包，还可能引发自动加载冲突。

为什么 `composer require phpunit/phpunit` 是错的

这条命令默认写入 require 区块，导致 PHPUnit 被当成生产依赖安装。线上执行 composer install --no-dev 时它仍会被拉下来，浪费资源、污染部署包，甚至干扰 autoloader（比如和 phpspec/prophecy 的类名冲突）。

正确命令是：composer require --dev phpunit/phpunit
如果已误装，先运行：composer remove phpunit/phpunit，再加 --dev 重装
PHP 版本要匹配：PHP 7.4 项目请用 phpunit/phpunit:^9.6，PHP 8.1+ 才能用 v10+

`autoload-dev` 不配，`tests/` 里的类就找不到

Composer 默认只 autoload src/ 下的类。测试类在 tests/ 目录里，必须显式告诉 autoloader 去扫它，否则 Class 'AppTestsExampleTest' not found 这类错误必现。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

在 composer.json 的 autoload-dev 下加 PSR-4 映射："App\Tests\": "tests/"
改完立刻执行：composer dump-autoload（不是 install 或 update）
别只写 autoload —— 它不包含 tests/，且某些测试框架（如 PHPUnit）会跳过它

`phpunit.xml` 里 `bootstrap` 路径写错，TestCase 都加载不了

没 phpunit.xml 也能跑，但默认行为极不可控：它递归扫描当前目录所有 *Test.php，可能加载到 vendor/ 里的测试文件，或漏掉你自己的。

最小可用配置必须含 bootstrap="vendor/autoload.php"，确保 Composer 自动加载器先就绪
<directory>tests</directory> 显式限定范围，避免误扫
别用全局 phpunit 命令——它不读当前项目的 phpunit.xml 和 autoload.php，版本也不受控
执行统一用：./vendor/bin/phpunit（Linux/macOS）或 vendorinphpunit（Windows）

`composer test` 脚本失效，八成是权限或路径问题

很多人在 composer.json 里写了 "test": "vendor/bin/phpunit"，却在 Windows 上跑失败，或提示 “command not found”。

Linux/macOS：确认 vendor/bin/ 下有可执行权限（chmod +x vendor/bin/phpunit）
Windows：实际调用的是 vendor/bin/phpunit.bat，脚本里写 vendor/bin/phpunit 也行，但得确保该 .bat 存在
CI 场景下建议加 --no-coverage 参数，避免因缺失 xdebug 导致测试中断
执行前务必确认：composer install --dev 已运行，且 vendor/bin/phpunit 文件真实存在

最常被忽略的一点：当你在测试中 mock 第三方类（比如 GuzzleHttpClient），而它又来自 require-dev 里的包（如 guzzlehttp/guzzle），那这个包就不能只出现在 require —— 否则本地测试通过，CI 却报 Class not found。dev 依赖的类路径，必须由 autoload-dev 覆盖，且不能指望生产 autoload 替你兜底。