global-coding-governance/java-coding-style/references/06-测试审查与验证.md

测试、审查与验证

测试设计

• 必须：测试代码放在项目约定的测试源集，通常为 src/test/java；不得把测试逻辑混入生产代码。
• 必须：每个测试具有清晰的 Arrange/Act/Assert 或 Given/When/Then 结构，一个失败能指出一个主要行为。
• 必须：测试独立、可重复、可并行时不互相污染；不得依赖执行顺序、真实当前时间、随机外网或共享生产数据。
• 必须：断言业务结果、状态变化和外部交互，不只断言“无异常”或覆盖实现细节。
• 推荐：遵循 AIR 原则：Automatic、Independent、Repeatable；覆盖 BCDE：Boundary、Correct、Design、Error。
• 必须：缺陷修复先加入能复现问题的测试；新行为先建立失败证据，再实现通过。
• 推荐：单元测试隔离自身职责，集成测试验证真实框架映射、事务、序列化和数据库行为。
• 必须：Mock 只隔离边界，不复刻被测实现；过多 Mock 通常提示职责或测试层级错误。
• 推荐：测试命名表达条件与预期，服从项目现有 JUnit/TestNG、Mockito、AssertJ 等风格。

风险用例

按任务选择至少检查：

• null、空值、最小/最大长度、零、负数、溢出、重复和非法枚举；
• 精度、舍入、字符编码、Locale、时区和夏令时；
• 超时、重试、重复请求、部分失败、事务回滚和幂等；
• 并发更新、锁竞争、中断、资源关闭和线程池拒绝；
• 未认证、未授权、越权、注入、恶意大输入和敏感信息泄漏；
• 序列化前后兼容、数据库映射和旧调用方行为。

Code Review 清单

1. 将每条需求映射到实现与至少一项验证证据。
2. 阅读完整 diff 和必要上下文，不只看新增行。
3. 检查是否覆盖用户已有改动或包含无关格式化。
4. 检查空值、异常、资源、并发、事务、数据规模和安全边界。
5. 检查 API、DTO、SQL、配置与依赖的兼容性。
6. 检查测试能在错误实现下失败，避免只验证 Mock 自己的返回。
7. 将发现按 阻断/严重/一般/建议 分级，并给出触发条件和影响。
8. 修复后重新阅读 diff 并重跑受影响验证。

命令选择

先从仓库文档和 CI 获取标准命令，常见候选仅供识别：

Maven:  ./mvnw test
Gradle: ./gradlew test

不要假定包装器、模块名或 profile 一定存在。优先运行：

1. 单个受影响测试；
2. 受影响模块测试；
3. 编译与项目配置的 formatter/Checkstyle/PMD/SpotBugs；
4. 风险要求的集成测试或全量构建。

项目已配置 P3C 时使用既有入口。若未配置，进行人工规则 Review，并把“未运行 P3C”明确写为未验证项，而不是临时修改构建。

结果报告

每项验证记录：

命令或检查：
范围：
结果：通过 / 失败 / 未执行
证据摘要：
失败或未执行原因：

只报告本次实际获得的证据。环境错误、既有失败和本次回归必须区分；无法确定归属时标记为待调查，不得猜测。