Test Coverage Analysis

Test Coverage Analysis

Current Coverage

• [X] 个测试覆盖了 [Y] 个函数/组件
• 已识别的覆盖缺口：[列表]

Recommended Tests

1. [测试名] — [它验证什么，为什么重要]
2. [测试名] — [它验证什么，为什么重要]

Priority

• Critical：[能捕获潜在数据丢失或安全问题的测试]
• High：[核心业务逻辑的测试]
• Medium：[边界情况与错误处理的测试]
• Low：[工具函数与格式化类测试]

这份报告的价值在 `/ship` 的合并阶段体现出来：`/ship` 是发布前的 fan-out 编排器，让 `code-reviewer`、`security-auditor`、`test-engineer` 三个子代理**并行**处理同一份变更，各自产出一份独立视角的报告（review report / audit report / **coverage report**），再由主代理在 Phase B 合并成 go/no-go 决策。test-engineer 报告中的 Priority 分级直接参与决策：Critical 级缺口（可能漏掉数据丢失或安全问题）会被提升为发布阻断项。

模板的 Priority 四级与代码评审的严重度标签（Critical / Required / Optional / Nit，定义在 [code-reviewer](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/agents/code-reviewer.md?utm_source=gitcode_repo_files) 与 [skills/code-review-and-quality/SKILL.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/skills/code-review-and-quality/SKILL.md?utm_source=gitcode_repo_files) 中）属于同一套沟通语言，三份报告才能被无损地合并。

## 八、七条测试规则

原文档的 Rules 一节是 test-engineer 的硬约束，逐条继承如下：

1. **测行为，不测实现细节**（Test behavior, not implementation details）；
2. **每个测试只验证一个概念**（one concept per test）；
3. **测试必须相互独立** —— 测试之间不共享可变状态；
4. **慎用快照测试**，除非你愿意审阅快照的每一次变更；
5. **只在系统边界 mock**（数据库、网络），不在内部函数之间 mock；
6. **每个测试名要读起来像一份规格**；
7. **一个从不失败的测试，和一个总是失败的测试一样没用**（A test that never fails is as useless as a test that always fails）。

第 7 条与 TDD 技能 “Red Flags” 一节呼应：“第一次运行就通过的测试（它可能根本没在测你以为的东西）”是被点名的危险信号。规则 4 对应 TDD 技能反模式表中的 “Snapshot abuse：没人审阅的大快照，任何改动都炸”。

## 九、如何调用 test-engineer：三种方式与一条红线

原文档末尾的 Composition 块明确声明了这个 persona 在编排体系中的位置：

- **直接调用（Invoke directly when）**：当用户请求测试设计、覆盖度分析，或为某个具体 Bug 写 Prove-It 测试时。典型提示如 “What tests are missing for the checkout flow?”（结账流程缺什么测试？）；
- **经命令调用（Invoke via）**：`/test`（TDD 工作流）或 `/ship`（与 `code-reviewer`、`security-auditor` 并行 fan-out 做覆盖度缺口分析）；
- **禁止红线（Do not invoke from another persona）**：persona 不得调用另一个 persona。“建议加测试”的内容应写进报告里，何时行动由用户或斜杠命令决定——编排是斜杠命令（和用户）的职责，不是角色的职责。

### `/ship` 中的并行 fan-out 为什么成立

从 [docs/agents.md](https://gitcode.com/GitHub_Trending/agentskill/agent-skills/blob/020ec10a788f5703108d093a4bd3d9a7c3847d36/docs/agents.md?utm_source=gitcode_repo_files) 的决策矩阵看，fan-out 只适用于**子任务相互独立**（无共享可变状态、无执行顺序依赖）的场景：

```
工作是不是对单一工件的单一视角？
├── 是 → 直接调用 persona
└── 否 → 子任务是否独立（无共享可变状态、无顺序要求）？
         ├── 是 → 带并行 fan-out 的斜杠命令（如 /ship）
         └── 否 → 用户按顺序跑的斜杠命令（/spec → /plan → /build → /test → /review）
```

`/ship` 正是这个仓库唯一认可的编排模式：

```
/ship
  ├── (并行) code-reviewer    → review report
  ├── (并行) security-auditor → audit report
  └── (并行) test-engineer    → coverage report
                  ↓
        合并阶段（主代理）
                  ↓
        go/no-go 决策 + 回滚计划