6aspec 3.0.0-dev.18 → 3.0.0-dev.19
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -42,6 +42,10 @@
|
|
|
42
42
|
- 若本任务引入/修改**可执行业务逻辑**（如 Service/Domain/校验/计算/流程编排）或修复缺陷：在项目有测试框架时补充/修改对应单元测试，覆盖任务关联的 AC/Scenario；若无测试框架则说明验证方式与回归点
|
|
43
43
|
- 若本任务主要为纯数据结构、**SQL/DDL/迁移脚本**、或**薄持久化**（见上）：默认不强制单元测试；改为提供可审查的验证清单，并在报告中标注风险
|
|
44
44
|
- **禁止**：把「本任务动到了 Repository/Mapper」**单独**当成必须写单测的理由；是否写单测取决于是否出现**非平凡逻辑**（分支、规则、补偿、复杂 SQL 行为），以及 TASK/specs 是否点名要自动化测试
|
|
45
|
+
|
|
46
|
+
**🚨 测试红线（绝对禁止）**：
|
|
47
|
+
- **禁止在测试代码中重新实现被测逻辑**：不得在测试方法里自己写 stream filter、循环、条件判断等来"模拟"业务行为后再断言结果——这类测试无论业务代码是否正确都会通过，没有任何验证价值。
|
|
48
|
+
- **测试必须调用被测类的真实方法**：通过断言其返回值，或通过 mock verify 断言其对依赖的调用行为来验证。合法结构示例：`given(mock).thenReturn(x)` → 调用 `service.realMethod(...)` → `assertEquals(expected, result)` 或 `verify(mock).someMethod(...)`。
|
|
45
49
|
7. 完成后自我审查，报告结果
|
|
46
50
|
|
|
47
51
|
## 自我审查
|
|
@@ -54,7 +58,10 @@
|
|
|
54
58
|
|
|
55
59
|
**一致性**：是否遵循了现有代码风格、`code.md` 与 design.md 的技术决策？
|
|
56
60
|
|
|
57
|
-
**分层**：若本次改动涉及 Controller/API
|
|
61
|
+
**分层**：若本次改动涉及 Controller/API、事件订阅、消息消费或调度入口，执行以下客观计数检查（有 TASK/design 明确例外除外）：
|
|
62
|
+
- 数一数入口类核心方法中对**外部系统**（Gateway、Repository、其他 Service）的调用次数：**超过 1 次即违规**，说明编排逻辑未下沉到 Service。
|
|
63
|
+
- 检查入口类是否存在**私有业务方法**（含 stream 聚合、多分支判断、远程查询封装等）：有则违规，这些逻辑应在 Service 中实现。
|
|
64
|
+
- 合法的入口方法结构：解析入参 → 日志 → 调一次 Service → 返回结果。不符合此结构须重构后再报告。
|
|
58
65
|
|
|
59
66
|
**测试/验证**：
|
|
60
67
|
- 若 **`skipTest=true`**：是否已说明验证方式、回归点与残余风险？若 TASK/specs 强制要求测试而与参数冲突，是否已上报或已按主 agent 取舍执行？
|