Webman集成PHPUnit的关键在于绕过HTTP封装层，让测试直触业务逻辑：phpunit.xml的bootstrap必须指向自定义tests/bootstrap.php，显式加载配置、容器、启动引导类，并将Controller业务抽离至Service层进行单元测试。
Webman 集成 PHPUnit 不是“装上就能跑”，关键在于绕过它的 HTTP 服务封装层，让测试直接触达业务逻辑。否则你会卡在 Cannot start Webman server in CLI mode 或测试始终不加载配置、路由、容器依赖——这是最常被忽略的起点。
phpunit.xml 的 bootstrap 必须指向可执行的初始化入口
Webman 的 bootstrap 不能只写 vendor/autoload.php，它不加载框架配置和容器实例。必须用自定义 tests/bootstrap.php 显式启动 Webman 的初始化流程：
-
require_once __DIR__ . '/../vendor/autoload.php'是基础，但仅此不够 - 必须调用
Webman\Config::load()加载config/下的配置（尤其是route和container） - 必须遍历
config('bootstrap', [])并执行每个类的::start()，否则中间件、事件监听器等不会注册 - 时区、自动加载文件（
autoload.files）也得手动补全，否则测试中date_default_timezone_get()可能报错或行为不一致
测试类里不能 new Controller 或直接 dispatch 请求
Webman 的 Controller 严重依赖 Request、Response 和容器注入，裸 new 会触发 Call to a member function input() on null 类错误。正确做法是：
- 把 Controller 中的业务逻辑抽离到独立 Service 类，对 Service 写单元测试（这才是真正的单元测试）
- 若必须测 HTTP 行为，改用
Webman\Http\Request和Webman\Http\Response构造实例，再手动调用 Controller 方法，传入 mock 的 Request - 避免在测试中调用
Route::dispatch()—— 它会启动完整请求生命周期，引入不可控副作用
IDE（如 PHPStorm）配置时 Path mappings 别乱填 Remote Path
用 Docker + PHPStorm 跑 Webman 测试时，很多人在 Cli Interpreter → Path mappings 里误填 Remote Path，结果测试总报 Class not found。真相是：
立即学习“PHP免费学习笔记（深入）”；
- Docker 容器内路径与宿主机一致时，
Remote Path栏位**留空即可**，填了反而导致路径映射错乱 - 只需确保
Local path指向项目根目录，且容器内工作目录（WORKDIR）与之相同 - 如果用了 volume 挂载，确认挂载路径没覆盖掉
/var/www/html/vendor这类关键目录
运行命令别漏掉 --no-configuration 或显式指定配置
Webman 项目常有多个 phpunit.xml 变体（比如 CI 用 dist 版），但默认 ./vendor/bin/phpunit 会优先找当前目录下的配置。容易踩的坑：
- 在
tests/子目录下执行phpunit Test.php，PHPUnit 会向上递归找phpunit.xml，可能误加载父级错误配置 - 建议统一用
./vendor/bin/phpunit --configuration phpunit.xml显式指定，避免歧义 - 调试时加
--debug查看实际加载了哪些测试文件和 bootstrap 脚本，比猜快得多
最难的不是写断言，而是让 Webman 的容器、配置、路由在测试上下文中真正“活”起来——这一步没做实，后面所有测试都是空中楼阁。
