SWUSTcyt Verify-Test：三层测试
概述
为实现建立三层测试覆盖：单元测试、功能测试、使用示例（Examples）；并在编码前先出测试计划。
核心原则： 测试用例前置——先想清楚「要验证什么」，再写实现。
何时使用
- 实现一个 Issue 时（与 execute-implement 配套）
- 编码前制定测试计划
- 修 Bug 时先写复现测试
三层测试体系
| 层级 | 覆盖范围 | 要求 |
|---|---|---|
| 单元测试 | 函数/方法的正常路径 + 边界 + 异常 | 覆盖率 ≥ 80% |
| 功能测试 | API/模块完整请求-响应链路 | 至少 1 正常 + 1 异常 |
| Examples | API/模块典型用法 | 2-3 个实际使用场景 |
流程
- 出测试计划 — 编码前列出测试场景（正常 / 边界 / 异常）+ 预期结果，交用户确认。
- 写单元测试 — 覆盖正常、边界、异常三类输入。
- 写功能测试 — 至少一条正常链路 + 一条异常链路。
- 写 Examples — 2-3 个真实用法示例。
- 本地跑全绿 — 提交前测试、lint 全部通过（本地/单人即 L1 自动验收）。
验收硬规则（功能不回退）：凡声称「功能不回退 / 可用」，必须至少跑通一次关键路径的真实端到端冒烟（真实模型 / 外部服务 / 工具链，而非仅构建或起服务）。若因缺密钥、环境等跑不了，该项只能标 blocked / 待人工，不得标 done。「构建通过」「服务能起来」只是 L1 烟雾，不等于功能测试。
产出
- 三层测试代码 + 测试计划（场景 + 预期）
提示词参考
为以下函数编写单元测试，覆盖正常输入、边界值、异常输入三种情况；再补一条正常 + 一条异常的功能测试，以及 2-3 个使用示例。
常见错误
- 只测正常路径 → 边界与异常是 Bug 高发区，必须覆盖。
- 测 mock 而非真实行为 → 测试通过但代码可能错。优先真实代码，mock 仅在不可避免时用。
- 编码后才补测试 → 测试被实现带偏，沦为「描述现状」而非「定义预期」。坚持前置。
- 用「构建通过 / 服务起得来」冒充「功能不回退」 → 构建烟雾和起服务只能证明能加载，证明不了业务链路。关键路径必须真实端到端走一遍；跑不了就标 blocked，别给假绿灯。
参考
- 配套：
skills/execute-implement/SKILL.md、skills/verify-review/SKILL.md - 借鉴：
reference/vendored-skills/superpowers/skills/test-driven-development - 方法论出处：唯一真源
docs/AI 编程方法论 v1.2 — 可操作版.md第 3.1 / 3.3 节