Laravel/PHPUnit：依赖中间件的路由测试方案咨询

API 探路者

2026-5-25

嘿，这个问题我之前帮不少开发者梳理过，咱们一步步来拆解你的两个核心疑问——保留Middleware时的API测试方案，以及Middleware和控制器的耦合是否合理。

一、不移除Middleware的前提下测试API端点

其实有几种实用的方案，完全不用动线上的Middleware逻辑：

手动在测试中为请求注入$user
很多框架都允许在测试时自定义请求对象。你可以先创建一个测试用的用户实例，然后把它直接附加到请求的$user属性上，再发送请求。这样Middleware校验逻辑触发时，会发现请求里已经有合法用户，直接通过校验（或跳过冗余的校验步骤）。举个伪代码例子：
```
// 测试代码
$testUser = User::factory()->create();
$request = Request::create('/api/endpoint', 'GET');
$request->user = $testUser; // 直接注入用户

$response = $this->sendRequest($request);
// 断言响应符合预期
```

Mock Middleware的校验逻辑
如果你的Middleware是通过容器实例化的，测试时可以替换它的实现。用Mock框架创建一个Middleware替身，让它的handle方法直接通过校验，并给请求附加$user。这样既保留了Middleware在请求流程中的位置，又跳过了实际的校验操作（比如调用Auth服务、数据库查询等）。伪代码大概是这样：

// 测试前绑定Mock的Middleware
$mockMiddleware = $this->createMock(AuthMiddleware::class);
$mockMiddleware->method('handle')
               ->willReturnCallback(function ($request, $next) {
                   $request->user = User::factory()->create();
                   return $next($request);
               });
$this->app->bind(AuthMiddleware::class, fn () => $mockMiddleware);

// 发送请求测试
$response = $this->get('/api/endpoint');

使用框架自带的测试辅助工具
很多现代框架都有专门的测试助手，比如Laravel的actingAs()方法，它会自动帮你处理用户认证，本质就是在请求流程中提前注入用户，让Middleware的校验逻辑直接通过。这种方法最省心，不用手动操作请求对象：
```
$testUser = User::factory()->create();
$response = $this->actingAs($testUser)->get('/api/endpoint');
```

二、Middleware与控制器耦合是否属于不良实践？

这个得分情况看，不能一概而论：

不算强耦合的场景
如果控制器只是通过请求对象（比如$request->user）获取用户，这其实是依赖请求契约，而非直接依赖Middleware本身。只要框架保证请求对象的接口稳定，这种依赖是合理的——Middleware负责填充请求对象的属性，控制器只关心“请求里有没有合法用户”，不关心用户的来源，耦合度很低。
需要警惕的隐式依赖
但如果控制器直接依赖Middleware添加的自定义非标准属性（比如$request->customUserExtraData，而非框架自带的user()方法），这就属于隐式依赖了。新人接手代码时可能不知道这个属性是Middleware注入的，调试和维护成本会很高，这种情况属于不良实践，建议优化：
1. 用依赖注入代替：把用户实例直接注入控制器方法，而非从请求中获取；
2. 定义自定义请求类：创建封装了用户获取逻辑的请求类，控制器依赖这个自定义类而非原生请求；
3. 借助服务容器：把用户实例绑定到容器，控制器从容器获取用户，而非从请求中提取。

你提到的“在应用实例中部分Mock并替换Middleware”的思路完全可行，尤其是在需要测试控制器纯业务逻辑、不想被Middleware校验逻辑干扰时。这种方法在集成测试或单元测试中都很常用，既保留了请求流程的完整性，又能精准隔离测试关注点。

内容的提问来源于stack exchange，提问作者Victor Mikó