Back to Details

test-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Test Review

测试评审

Review test quality and audit coverage gaps by loading the project testing standards first, then executing the audit workflow. The pipeline produces a prioritized gap report — not test code.
通过先加载项目测试标准，再执行审计工作流，来评审测试质量并审计覆盖缺口。该流程生成的是按优先级排序的缺口报告，而非测试代码。

When to Use

使用场景

  • "Review the tests for module X"
  • "Audit test coverage for this component"
  • "Are these tests any good?"
  • "What tests are missing?"
  • Before writing new tests (audit first, then write)
  • After a significant refactor (verify tests still cover the contract)
  • When preparing a module for production
  • "评审模块X的测试"
  • "审计该组件的测试覆盖率"
  • "这些测试质量如何？"
  • "缺少哪些测试？"
  • 编写新测试之前（先审计，再编写）
  • 重大重构之后（验证测试是否仍覆盖契约）
  • 模块准备上线时

Pipeline

工作流程

This skill is a three-phase pipeline. Execute the phases in order. Do not skip Phase 1 — the standards must be loaded before reviewing any test code.
该技能是一个三阶段流程。请按顺序执行各阶段，切勿跳过第一阶段——在评审任何测试代码前，必须先加载标准。

Phase 1: Load the Standards

阶段1：加载标准

Read the project testing standards to calibrate what "good" looks like:
cat skills/test-review/references/testing-standards.md
This file defines:
  • Anti-patterns to flag (mirror testing, happy-path-only, over-mocking, trivial assertions)
  • Required test categories (contract, boundary, failure mode, state transition, integration)
  • The self-check checklist for individual tests
  • Language-specific standards (Rust, TypeScript/React)
  • Coverage expectations by component type
  • Naming conventions
Internalize these before reading any test code. Every finding in the audit must reference a specific standard from this file. Do not invent standards — use the ones defined here.
阅读项目测试标准，明确“优质测试”的定义：
cat skills/test-review/references/testing-standards.md
该文件定义了：
  • 需要标记的反模式（镜像测试、仅覆盖正常路径、过度Mock、无意义断言）
  • 必需的测试类别（契约、边界、故障模式、状态转换、集成）
  • 单个测试的自检清单
  • 特定语言标准（Rust、TypeScript/React）
  • 按组件类型划分的覆盖率要求
  • 命名规范
在阅读任何测试代码前，请先吃透这些内容。 审计中的每一项发现都必须引用该文件中的特定标准。请勿自行制定标准——仅使用此处定义的标准。

Phase 2: Discovery (Haiku Agents)

阶段2：发现（Haiku Agents）

Spawn Haiku sub-agents to perform the mechanical discovery work — Steps 1 and 2 of the audit workflow. This keeps the main context clean for analysis.
Read the audit workflow first so you understand what the agents need to do:
cat skills/test-review/references/audit-workflow.md
启动Haiku子代理来执行机械性的发现工作——即审计工作流的第1步和第2步。这能让主上下文保持清晰，以便进行分析。
请先阅读审计工作流，了解代理需要执行的任务：
cat skills/test-review/references/audit-workflow.md

Step 2a: Scope the work

步骤2a：确定工作范围

Before spawning agents, determine how many files are involved:
Glob tool: **/*.{py,rs,ts,tsx,js,jsx,go,rb} under [MODULE_PATH]
Glob tool: **/*.{test,spec}.* or **/test_*.* or **/tests/**  under [TEST_PATH]
Count the source files and test files. This determines the fan-out strategy.
在启动代理前，先确定涉及的文件数量：
Glob工具：[MODULE_PATH]下的**/*.{py,rs,ts,tsx,js,jsx,go,rb}
Glob工具：[TEST_PATH]下的**/*.{test,spec}.* 或 **/test_*.* 或 **/tests/**
统计源文件和测试文件的数量，这将决定分流策略。

Step 2b: Choose fan-out strategy

步骤2b：选择分流策略

Source filesStrategyAgents
≤ 15Single agent — one Haiku handles everything1
16–60Partition by directory — one agent per top-level subdirectory (or logical grouping)2–4
60+Partition by file chunks — split the file list into roughly equal chunks of ~15 files eachup to 6
Partitioning rules:
  • Each agent gets a subset of source files to inventory (Step 1)
  • Each agent also gets the full test file list (tests may cross-cut source boundaries)
  • Each agent only produces inventory for its assigned source files
  • Partitions should respect directory boundaries when possible (keep related files together)
源文件数量策略代理数量
≤ 15单代理 —— 一个Haiku处理所有工作1
16–60按目录划分 —— 每个顶级子目录（或逻辑分组）分配一个代理2–4
60+按文件块划分 —— 将文件列表大致分成每份约15个文件的均等块最多6个
划分规则：
  • 每个代理分配一部分源文件进行盘点（步骤1）
  • 每个代理同时获取完整的测试文件列表（测试可能跨源文件边界）
  • 每个代理仅为其分配的源文件生成盘点结果
  • 尽可能遵循目录边界进行划分（将相关文件放在一起）

Step 2c: Launch agents in parallel

步骤2c：并行启动代理

Launch all Haiku agents in a single message so they run concurrently. Each agent gets the same instructions but a different file partition.
Do not ask Haiku agents to analyze, prioritize, or judge. Their job is to read code and produce a factual inventory. Analysis happens in Phase 3.
Single agent (≤ 15 source files):
Task tool:
  subagent_type: Explore
  model: haiku
  prompt: |
    Read the audit workflow at skills/test-review/references/audit-workflow.md.
    Then execute Steps 1 and 2 for the module at [MODULE_PATH].

    Step 1 - Map the Public Contract:
    Read every source file in the module. List every public behavior it promises
    as plain-English statements (see audit-workflow.md for format and examples).

    Step 2 - Map Existing Test Coverage:
    Read every test file that covers this module. For each test, record what
    behavior it exercises and whether assertions are meaningful. Mark each
    behavior from Step 1 as:
    - Covered: at least one test verifies this with meaningful assertions
    - Shallow: a test touches this but doesn't properly verify it
    - Missing: no test exercises this behavior

    Return:
    1. Source files read (paths)
    2. Test files read (paths)
    3. Complete behavior list with coverage status markers
    4. For each Shallow entry, note what the test does and why it's insufficient

    Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.
Multiple agents (16+ source files):
Launch all agents in the same message. Each gets a partition of source files but the full list of test files.
undefined
在同一条消息中启动所有Haiku代理，以便它们并发运行。每个代理接收相同的指令，但处理不同的文件分区。
请勿要求Haiku代理进行分析、优先级排序或评判。 它们的任务是读取代码并生成事实性盘点结果。分析工作在阶段3进行。
单代理（≤15个源文件）：
Task tool:
  subagent_type: Explore
  model: haiku
  prompt: |
    Read the audit workflow at skills/test-review/references/audit-workflow.md.
    Then execute Steps 1 and 2 for the module at [MODULE_PATH].

    Step 1 - Map the Public Contract:
    Read every source file in the module. List every public behavior it promises
    as plain-English statements (see audit-workflow.md for format and examples).

    Step 2 - Map Existing Test Coverage:
    Read every test file that covers this module. For each test, record what
    behavior it exercises and whether assertions are meaningful. Mark each
    behavior from Step 1 as:
    - Covered: at least one test verifies this with meaningful assertions
    - Shallow: a test touches this but doesn't properly verify it
    - Missing: no test exercises this behavior

    Return:
    1. Source files read (paths)
    2. Test files read (paths)
    3. Complete behavior list with coverage status markers
    4. For each Shallow entry, note what the test does and why it's insufficient

    Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.
多代理（16+个源文件）：
在同一条消息中启动所有代理。每个代理分配一部分源文件，但获取完整的测试文件列表。
undefined

Agent 1 of N — launched in parallel with all other agents

Agent 1 of N — launched in parallel with all other agents

Task tool: subagent_type: Explore model: haiku prompt: | Read the audit workflow at skills/test-review/references/audit-workflow.md. Then execute Steps 1 and 2 for the following SOURCE FILES ONLY: [LIST OF FILES IN THIS PARTITION]
The test files that may cover these sources are at:
[FULL TEST FILE LIST OR TEST DIRECTORY PATH]

Step 1 - Map the Public Contract:
Read ONLY the source files listed above. List every public behavior each
promises as plain-English statements (see audit-workflow.md for format).

Step 2 - Map Existing Test Coverage:
Read the test files and identify which tests exercise behaviors from YOUR
source files. Mark each behavior as:
- Covered: at least one test verifies this with meaningful assertions
- Shallow: a test touches this but doesn't properly verify it
- Missing: no test exercises this behavior

Return:
1. Source files you read (paths)
2. Test files you read (paths)
3. Complete behavior list with coverage status markers
4. For each Shallow entry, note what the test does and why it's insufficient

Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.
Task tool: subagent_type: Explore model: haiku prompt: | Read the audit workflow at skills/test-review/references/audit-workflow.md. Then execute Steps 1 and 2 for the following SOURCE FILES ONLY: [LIST OF FILES IN THIS PARTITION]
The test files that may cover these sources are at:
[FULL TEST FILE LIST OR TEST DIRECTORY PATH]

Step 1 - Map the Public Contract:
Read ONLY the source files listed above. List every public behavior each
promises as plain-English statements (see audit-workflow.md for format).

Step 2 - Map Existing Test Coverage:
Read the test files and identify which tests exercise behaviors from YOUR
source files. Mark each behavior as:
- Covered: at least one test verifies this with meaningful assertions
- Shallow: a test touches this but doesn't properly verify it
- Missing: no test exercises this behavior

Return:
1. Source files you read (paths)
2. Test files you read (paths)
3. Complete behavior list with coverage status markers
4. For each Shallow entry, note what the test does and why it's insufficient

Do NOT prioritize, analyze risk, or produce a gap report. Just inventory.

Agent 2 of N — same structure, different file partition

Agent 2 of N — same structure, different file partition

...

...

Agent N of N

Agent N of N

undefined
undefined

Step 2d: Merge inventories

步骤2d：合并盘点结果

Once all agents return, merge their results into one unified inventory:
  1. Concatenate all behavior lists (each agent covers different source files, so there should be minimal overlap)
  2. Deduplicate any behaviors that appear in multiple agents' results (can happen when source files in different partitions share interfaces)
  3. Prefer the more-specific status when merging duplicates: if one agent says Covered and another says Shallow for the same behavior, keep Shallow (investigate the discrepancy in Phase 3)
  4. Compile the full list of source files and test files read across all agents
The merged inventory feeds into Phase 3 exactly as if a single agent produced it.
所有代理返回结果后，将它们的结果合并为一份统一的盘点清单：
  1. 拼接所有行为列表（每个代理覆盖不同的源文件，因此重叠应极少）
  2. 去重多个代理结果中出现的重复行为（当不同分区的源文件共享接口时可能发生）
  3. 合并重复项时优先保留更具体的状态：如果一个代理标记为Covered，另一个标记为Shallow，则保留Shallow（在阶段3调查差异）
  4. 汇总所有代理读取的源文件和测试文件的完整列表
合并后的盘点清单将直接用于阶段3，就像由单个代理生成的一样。

Phase 3: Analysis and Report

阶段3：分析与报告

Using the merged Haiku inventory, you (the main agent) perform the deeper analysis work — Steps 3 and 4 of the audit workflow:
  • Step 3: Adversarial analysis — probe input boundaries, error handling, state, integration seams. Use the questions from audit-workflow.md against the behavior inventory. You may need to read specific source files to answer them.
  • Step 4: Produce the gap report — assign P0/P1/P2 priorities using the criteria defined in audit-workflow.md, cite testing-standards.md rules, and produce the full report in the format specified.
The adversarial analysis and priority assignment require judgment that only the main agent should perform. Do not delegate these to a sub-agent.
使用合并后的Haiku盘点清单，你（主代理）执行更深入的分析工作——即审计工作流的第3步和第4步：
  • 步骤3：对抗性分析 —— 探查输入边界、错误处理、状态、集成接缝。针对行为清单使用audit-workflow.md中的问题。你可能需要阅读特定源文件来回答这些问题。
  • 步骤4：生成缺口报告 —— 使用audit-workflow.md中定义的标准分配P0/P1/P2优先级，引用testing-standards.md中的规则，并按指定格式生成完整报告。
对抗性分析和优先级分配需要判断力，仅应由主代理执行。请勿将这些工作委托给子代理。

Operating Rules

操作规则

  1. Standards first, always. Read testing-standards.md before opening any test file. If context has been compressed and the standards are no longer loaded, read them again.
  2. Report, do not fix. The output is a gap report. Do not write test code unless explicitly asked to implement specific gaps from an approved report.
  3. Cite the standard. Every finding must name which testing-standards.md rule it violates or which audit-workflow.md criterion it fails. Findings without citations are opinions, not audit results.
  4. Read the source, not just the tests. The audit requires reading the module source to map the public contract (Step 1 of audit-workflow.md). Do not audit tests in isolation — the whole point is to find gaps between what the code does and what the tests verify.
  5. Do not manufacture gaps. If a module is well-tested, say so. The gap report has a "Well-Tested" section for exactly this purpose.
  1. 始终优先加载标准。在打开任何测试文件前，先阅读testing-standards.md。如果上下文被压缩，标准不再加载，请重新阅读。
  2. 仅生成报告，不修复问题。输出内容为缺口报告。除非明确要求根据已批准的报告实现特定缺口，否则请勿编写测试代码。
  3. 引用标准。每一项发现都必须指明它违反了testing-standards.md中的哪条规则，或未满足audit-workflow.md中的哪项标准。未引用标准的发现只是观点，而非审计结果。
  4. 阅读源文件，而非仅测试文件。审计需要读取模块源文件来映射公共契约（audit-workflow.md的步骤1）。请勿孤立地审计测试——核心目标是找出代码实际功能与测试验证内容之间的缺口。
  5. 勿凭空制造缺口。如果模块测试完善，请如实说明。缺口报告专门设有“测试完善”部分用于此类情况。

Modes

模式

Full Audit (default)

完整审计（默认）

Execute all three phases. Produces the full gap report.
Use when: "audit tests for module X", "review test coverage", preparing for production.
执行所有三个阶段，生成完整的缺口报告。
适用场景：“审计模块X的测试”、“评审测试覆盖率”、准备上线时。

Quick Review

快速评审

Load testing-standards.md, then review specific test files against the anti-patterns and self-check checklist only. Skip Phase 2 (Haiku discovery) and the adversarial analysis.
Use when: reviewing a PR's test changes, spot-checking a single test file, "are these tests ok?"
加载testing-standards.md，然后仅针对反模式和自检清单评审特定测试文件。跳过阶段2（Haiku发现）和对抗性分析。
适用场景：评审PR中的测试变更、抽查单个测试文件、“这些测试没问题吧？”

Write Mode

编写模式

Execute a full audit first, present the gap report, then — only after approval — write test implementations for approved gaps following the standards in testing-standards.md.
Use when: "audit and fix tests for module X", "write missing tests".
先执行完整审计，提交缺口报告，然后——仅在获得批准后——按照testing-standards.md中的标准为已批准的缺口编写测试实现。
适用场景：“审计并修复模块X的测试”、“编写缺失的测试”。

Common Mistakes

常见错误

  • Skipping testing-standards.md — Reviewing tests without loading the standards produces generic feedback. The standards are project-specific and opinionated.
  • Writing tests before the report — The audit produces findings. The user decides which to implement. Do not jump ahead.
  • Auditing tests without reading source — Cannot identify missing coverage without knowing what the code does.
  • Citing severity without justification — P0/P1/P2 assignments have specific criteria defined in audit-workflow.md. Use those criteria, not gut feeling.
  • 跳过testing-standards.md —— 未加载标准就评审测试会产生通用反馈。标准是项目特定且带有倾向性的。
  • 在报告生成前编写测试 —— 审计产生发现结果，由用户决定要实现哪些内容。请勿提前行动。
  • 未阅读源文件就审计测试 —— 不了解代码功能就无法识别缺失的覆盖率。
  • 未说明理由就标注严重程度 —— P0/P1/P2的分配在audit-workflow.md中有具体标准。请使用这些标准，而非直觉判断。