test-suite-builder

测试套件构建器

源映射：源自 Kotlin_Spring_Developer_Pipeline.md（SK-14）的一级关键技能。

使命

选择能够证明行为的最轻量级测试。 生成能够捕获回归问题的测试，而不是逐行复现实现。

从测试策略开始

编写代码前，先对需要证明的内容进行分类：

• 纯业务逻辑
• HTTP 契约和验证
• 仓库查询行为
• 序列化行为
• 安全规则
• 跨组件集成
• 数据库或消息代理集成

三层策略

• 使用单元测试验证领域逻辑、计算、决策表和确定性分支。
• 使用切片测试验证框架边界：
  • 对 HTTP 使用 @WebMvcTest 或 WebTestClient
  • 对仓库使用 @DataJpaTest
  • 在项目支持时，使用专注于 JSON 或安全的切片测试
• 仅当需要验证真实的应用组件图或基础设施边界时，才使用 @SpringBootTest 和 Testcontainers。

Kotlin 测试规则

• 优先使用 JUnit 5。
• 除非仓库已统一使用其他工具，否则优先使用 MockK 而非 Mockito。
• 符合项目风格时，使用易读的反引号测试名称。
• 对协程密集型代码使用 runTest 和协程测试工具包。
• 使用可复用的测试数据、构建器或对象母体，避免重复内联构造对象。

覆盖内容

• 成功路径。
• 验证失败。
• 业务规则失败。
• 与可空性、可选字段、空集合和重复项相关的边缘情况。
• 至少添加一个针对引发此次工作的问题或变更的回归测试。

不要做的事

• 如果切片测试或单元测试已足够，不要默认使用 @SpringBootTest。
• 不要只验证模拟对象的交互、却无法证明任何可观察结果的测试。
• 如果公共行为足以满足要求，不要让断言依赖私有实现细节。
• 不要在未加控制的情况下使用真实时间、随机值或共享可变状态。

输出约定

返回以下部分：

• Test plan：说明要使用哪些层以及原因。
• Generated tests：具体的测试类或补丁计划。
• Test data support：要添加的构建器、测试数据或工厂。
• Coverage gaps：仍未覆盖的重要情况。
• Verification：要运行的命令，以及修复前应失败的测试。

框架专项检查

• 根据 MVC 或 WebFlux 匹配使用 MockMvc 还是 WebTestClient。
• 根据仓库中的实际数据库或消息代理配置 Testcontainers。
• 如果问题涉及序列化或验证，应添加能证明线路契约的测试，而不只是服务逻辑测试。
• 如果事务行为很重要，应添加能在真实持久化层中证明回滚或唯一性行为的测试。

高级测试注意事项

• 总是回滚的事务测试可能会掩盖提交时的失败。涉及唯一约束、触发器或事务监听器时，应使用显式刷新或真实提交边界。
• 当方言、JSON、锁、索引使用或事务语义很重要时，H2 不能安全地替代 Postgres 或 MySQL。对于这些情况，优先使用 Testcontainers 运行真实数据库引擎。
• @MockBean 功能强大，但开销也大。过度使用会让集成测试变成运行缓慢、隐藏依赖装配问题的单元测试。
• 安全测试通常应同时验证 401 和 403，而不只是授权成功的路径。
• 异步和事件驱动流程需要确定性的等待策略，例如受控调度器、闩锁或 Awaitility。不要到处散布休眠操作。
• 无法通过单线程回滚测试证明并发和死锁行为。审查这些情况时，应使用多个事务并进行显式同步。
• 复用容器可以提速，但需要严格隔离状态。不要为了更快地通过构建而牺牲确定性。
• 当业务逻辑依赖时钟或 UUID 时，应使用确定性的时间和 ID 提供器。

专家启发式原则

• 如果 Bug 是由框架接线导致的，至少添加一个高于单元测试层级的测试。
• 如果 Bug 是由领域分支逻辑导致的，不要为了修复而引入整个 Spring 上下文。
• 如有疑问，选择能在变更前失败的最小测试。
• 将测试代码视为生产代码，注重可读性和可维护性。测试夹具和辅助工具应减少冗余，而不是掩盖行为。

防护措施

• 确保测试具有确定性。
• 设置应明确，并且限定在当前场景内。
• 每项测试尽量只对应一个明确的失败原因。
• 不要悄悄在快速单元测试套件中引入耗时且依赖大量基础设施的测试。

质量标准

良好的技能运行结果应在可能时保持测试套件快速，并在必要时确保其真实性。 糟糕的运行结果会让项目充斥依赖大量上下文的测试、脆弱的模拟对象，并且没有清楚说明各测试层级存在的原因。