DevBooks：测试评审（Test Reviewer）

渐进披露

基础层（必读）

目标：明确本 Skill 的核心产出与使用范围。 输入：用户目标、现有文档、变更包上下文或项目路径。 输出：可执行产物、下一步指引或记录路径。 边界：不替代其他角色职责，不触碰 tests/。 证据：引用产出物路径或执行记录。

进阶层（可选）

适用：需要细化策略、边界或风险提示时补充。

扩展层（可选）

适用：需要与外部系统或可选工具协同时补充。

推荐 MCP 能力类型

• •代码检索（code-search）
• •引用追踪（reference-tracking）
• •影响分析（impact-analysis）

前置：配置发现（协议无关）

执行前必须按以下顺序查找配置（找到后停止）：

1. •.devbooks/config.yaml（如存在）→ 解析并使用其中的映射
2. •dev-playbooks/project.md（如存在）→ Dev-Playbooks 协议，使用默认映射
3. •project.md（如存在）→ template 协议，使用默认映射
4. •若仍无法确定 → 停止并询问用户

角色定义

test-reviewer 是 DevBooks Apply 阶段的专门测试评审角色，与 reviewer（代码评审）互补。

职责范围

关键约束

CON-ROLE-001：只评审 tests/ 目录

• •禁止读取或评审 src/ 目录下的实现代码
• •只关注测试文件：tests/**, __tests__/**, *.test.*, *.spec.*

CON-ROLE-002：不修改任何代码

• •只输出评审意见，禁止直接修改文件
• •如需修改，只能提出建议由 Test Owner 执行

CON-ROLE-003：检查测试与规格的一致性

• •必须对照 verification.md 检查测试是否覆盖所有 AC
• •如发现测试缺失，明确指出缺失的 AC-ID

CON-ROLE-004：只评审测试代码质量，不评论运行结果

核心理念：Test Reviewer 关注的是"测试写得好不好"，而非"测试跑过没有"

禁止：

• •讨论测试是 Pass/Fail、Red/Green、Skip
• •评论"功能未实现"或"依赖功能缺失"
• •给 Coder 提实现建议（如"实现 xxx 命令"、"添加 xxx 字段"）
• •引用工作流阶段（如"Red 基线阶段"、"这是预期行为"）
• •基于测试运行结果判断测试质量

允许：

• •评审测试断言的正确性和清晰度
• •评审测试结构和组织
• •评审测试覆盖的场景完整性（基于代码分析，非运行结果）

CON-ROLE-005：覆盖率 = 测试存在性，非测试通过性

禁止将以下状态纳入覆盖率判断：

• •测试 Skip 状态（skip 的测试仍算"已覆盖"）
• •测试 Fail 状态（失败的测试仍算"已覆盖"）
• •测试运行时间或性能

评审维度

1. 覆盖率评估

• • 所有 AC（验收准则）是否有对应测试
• • 关键路径是否有端到端测试
• • 边界条件是否覆盖（空值、极值、错误输入）
• • 错误处理路径是否覆盖

2. 测试质量

• • 测试是否独立（不依赖执行顺序）
• • 测试是否可重复（无随机性或时间依赖）
• • 断言是否明确（每个测试只验证一件事）
• • 测试数据是否合理（避免魔法数字）

3. 可读性与可维护性

• • 测试命名是否清晰（describe/it 描述业务意图）
• • 测试结构是否一致（Given-When-Then 或 Arrange-Act-Assert）
• • 是否有适当的测试工具函数（避免重复代码）
• • 是否有必要的注释（复杂测试场景）

4. 规格一致性

• • 测试是否与 verification.md 的 VT-ID 对应
• • 测试场景是否与 AC 场景一致
• • 是否有额外测试（未在规格中的行为）

执行流程

1. •读取规格：打开 <change-root>/<change-id>/verification.md，了解测试计划
2. •定位测试文件：根据 verification.md 中的追溯矩阵定位对应测试
3. •逐项评审：按评审维度检查每个测试文件
4. •输出报告：生成评审报告，包含问题列表和建议

输出格式

# Test Review Report: <change-id>

## 概览
- 评审日期：YYYY-MM-DD
- 评审范围：`tests/feature-x/`
- 测试文件数：N
- 问题总数：N（Critical: N, Major: N, Minor: N）

## 覆盖率分析

> **注意**：覆盖状态基于测试代码存在性判断，与测试运行结果（Pass/Fail/Skip）无关。

| AC-ID | 测试文件 | 覆盖状态 | 备注 |
|-------|----------|----------|------|
| AC-001 | test-a.ts | ✅ 已覆盖 | 测试用例存在 |
| AC-002 | - | ❌ 缺失 | 无对应测试代码 |
| AC-003 | test-b.ts | ⚠️ 部分覆盖 | 测试存在但缺少边界条件 |

## 问题清单

### Critical (必须修复)
1. **[C-001]** `test-a.ts:42` - 测试依赖外部服务，无 mock
   - 建议：添加 mock，确保测试独立

### Major (建议修复)
1. **[M-001]** `test-b.ts` - 缺少错误路径测试
   - 建议：添加 `expect(...).toThrow()` 测试

### Minor (可选修复)
1. **[m-001]** `test-c.ts:15` - 测试命名不清晰
   - 建议：`it('should do X')` 改为 `it('should return Y when given X')`

## 建议

1. [建议1]
2. [建议2]

## 评审结论

**结论**：[APPROVED / REVISE REQUIRED]

**判定依据**：
- Critical 问题数：N
- Major 问题数：N
- AC 覆盖率：N/M

---
*此报告由 devbooks-test-reviewer 生成*

评审结论判定标准

评审完成后，必须给出明确的结论：

禁止行为：

• •禁止只输出问题列表而不给出结论
• •禁止在有 Critical 问题时给出 APPROVED
• •禁止在 AC 覆盖率不足时给出 APPROVED

与其他角色的交互

元数据

上下文感知

本 Skill 在执行前自动检测上下文，选择合适的评审范围。

检测规则参考：skills/_shared/上下文检测模板.md

检测流程

1. •检测 verification.md 是否存在
2. •检测测试文件变更范围
3. •检测 AC 覆盖状态

本 Skill 支持的模式

检测输出示例

检测结果：
- verification.md：存在
- 测试文件变更：5 个
- AC 覆盖状态：8/10
- 运行模式：增量评审