本文详解 @WebFluxTest 无法识别控制器导致 404 的根本原因，并提供使用 @SpringBootTest + WebTestClient.bindToApplicationContext 的可靠替代方案，确保响应状态码与数据流验证准确无误。
本文详解 `@webfluxtest` 无法识别控制器导致 404 的根本原因，并提供使用 `@springboottest` + `webtestclient.bindtoapplicationcontext` 的可靠替代方案，确保响应状态码与数据流验证准确无误。
在 Spring WebFlux 应用中进行控制器层单元测试时，若测试始终返回 404 NOT_FOUND（而 Postman 或浏览器访问正常），大概率是测试上下文未正确加载目标控制器——这正是 @WebFluxTest 的典型陷阱：它默认仅扫描被测控制器类所在包及其子包下的 @Controller/@RestController，且不自动包含当前测试类所在包外的控制器。更关键的是，@WebFluxTest 在未显式指定 controllers = {...} 的情况下，可能完全跳过你的控制器类（尤其当包结构不匹配或存在组件扫描限制时）。
上述问题中，测试类与控制器类同名（均为 FluxAndMonoController）是一个严重隐患：JUnit 会因类名冲突导致 Spring 无法正确注入或注册控制器 Bean，进一步加剧 404。务必确保测试类命名规范（如 FluxAndMonoControllerTest），并避免与被测类同名。
✅ 推荐解决方案：改用 @SpringBootTest 配合手动构建 WebTestClient
@SpringBootTest
class FluxAndMonoControllerTest {
private WebTestClient webTestClient;
@Autowired
ApplicationContext context;
@BeforeEach
void setup() {
this.webTestClient = WebTestClient
.bindToApplicationContext(context) // 全量加载上下文，确保控制器注册
.configureClient()
.build();
}
@Test
void returnFlux() {
Flux<integer> responseBody = webTestClient.get()
.uri("/flux")
.accept(MediaType.APPLICATION_JSON)
.exchange()
.expectStatus().isOk() // ✅ 状态码验证通过
.returnResult(Integer.class)
.getResponseBody();
StepVerifier.create(responseBody)
.expectNext(1, 2, 3, 4) // 可链式调用 expectNext
.verifyComplete();
}
@Test
void returnFluxStream() {
Flux<integer> responseBody = webTestClient.get()
.uri("/fluxstream")
.accept(MediaType.valueOf(MediaType.APPLICATION_NDJSON_VALUE))
.exchange()
.expectStatus().isOk()
.returnResult(Integer.class)
.getResponseBody();
StepVerifier.create(responseBody)
.expectNext(1, 2, 3, 4)
.verifyComplete();
}
}</integer></integer>
? 关键要点说明：
- @SpringBootTest vs @WebFluxTest：前者启动完整上下文（含所有 @RestController），后者为切片测试，需精确配置（如 @WebFluxTest(FluxAndMonoController.class)）才能加载指定控制器；若配置疏漏，404 不可避免。
- bindToApplicationContext 是核心：它使 WebTestClient 与 Spring 容器深度集成，支持路由匹配、过滤器、安全配置等全链路行为，而非模拟 HTTP 层。
- @BeforeEach 中构建 client：确保每次测试获得干净、独立的客户端实例，避免状态污染。
- StepVerifier 链式调用优化：expectNext(1, 2, 3, 4) 比多次 expectNext() 更简洁可读。
- NDJSON 处理注意：/fluxstream 接口声明 produces = MediaType.APPLICATION_NDJSON_VALUE，测试中需显式 accept(...) 对应类型，否则可能因内容协商失败触发 406 或降级行为。
⚠️ 补充建议：
- 若坚持使用 @WebFluxTest，请明确指定控制器：@WebFluxTest(FluxAndMonoController.class)，并确认其包路径在 @SpringBootApplication 扫描范围内；
- 检查 application-test.yml 是否意外禁用了 WebFlux（如 spring.main.web-application-type: none）；
- 确保测试类位于 src/test/java 下，且与主应用类处于可扫描的包层级（如主类在 com.example.demo，测试类应在 com.example.demo 或其子包）。
通过以上配置，即可彻底解决 “Expected: 200 OK, Actual: 404 NOT_FOUND” 的测试失败问题，实现对响应状态、媒体类型及响应式数据流的精准断言。
