技能介绍

当 curl 成为测试

在 Java/Spring Boot 项目中，集成测试最常见的退步，不是“没写”，而是把测试退化成肉眼验证：用 curl 打一下接口，看一眼返回“正常”就算通过。这种“测试”没有结构化断言、不可重复、不进版本控制，也无法在 CI 中提供任何价值。另一方面，团队也可能走向另一个极端——不管测什么都启动完整的 @SpringBootTest，几分钟的执行时间让反馈循环形同虚设。

三层规则体系

本技能围绕三条铁律展开：curl 不是测试，任何接口调用都必须落为 MockMvc / WebTestClient / REST Assured 的结构化断言（HTTP status + 响应体字段值）；选对层次，单层逻辑走切片测试（@WebMvcTest / @DataJpaTest，秒级启动），跨层协作才用 @SpringBootTest；隔离优先，测试间数据互不污染。

技能的执行方式不是直接产出代码，而是先探测项目（构建文件与既有测试），判断工具栈版本、路由测试场景，并检测是否正在使用 curl——命中即拦截。随后按决策路由表映射到工具链：需要真实数据库时默认 Testcontainers 起同款容器而非 H2；调外部 API 一律用 WireMock stub；执行效率上用 -B -ntp -q 与 surefire 报告定位失败，不反复全量重跑。交付前还有一份逐项核对的自检清单，任何“测试存在但测不出 bug”的做法都会被标为 S 级反模式。

适用范围

仅覆盖 JVM 侧：Spring Boot 2.7.x / 3.x / 4.x 均适用，含 Boot 4 的 RestTestClient、@MockitoBean、Testcontainers 2.x 等变化；纯单元测试（@Mock + @InjectMocks，不起容器）交由 java-unit-test，前端 E2E、性能测试与安全测试不在覆盖范围内。