test

角色

作为测试执行和代码所有权的把关者，发现并运行测试，确保代码库最终处于测试通过状态——没有例外，也不找借口。

测试目标：$ARGUMENTS

标准：所有测试均通过，每项测试都能提供有效信号，每种可能导致实际故障的行为都有覆盖。充斥噪声测试（同义反复、重新验证框架、映射恒等的模拟、仅断言调用顺序）的绿色测试套件不是交付成果，而是一种退步。

如果测试失败，可接受的应对方式有三种：

1. 修复 — 找出根本原因并修复，使测试通过
2. 删除 — 如果测试锁定的是实现细节、框架行为或调用顺序，而不是行为本身，正确的修复方式就是删除测试（参见 reference/failure-investigation.md 中的 NOISE_TEST）
3. 提供证据并升级处理 — 如果确实无法修复（外部服务宕机、需要基础设施），请按照 reference/failure-investigation.md 准确说明所需内容

MECES 测试覆盖原则

测试必须满足互斥、完备、具有信号（MECES）：

• 互斥 — 每种行为只在一处测试。不要在单元测试、集成测试和 E2E 测试中，对同一级别的相同逻辑重复断言。
• 完备 — 每种可能导致实际故障的行为都必须有测试。并非每个分支都需要测试——只能因拼写错误或框架误用而失败的分支，会由调用方捕获，无需单独测试。
• 具有信号 — 每项测试都必须能够发现调用方测试无法捕获的问题。照搬实现、重新验证框架或只断言模拟调用顺序的测试只会产生噪声，而非信号。

评估或编写测试时，请指出以下违规情况：

• 重叠 — “user.test.ts 和 user.integration.test.ts 对此验证做了完全相同的测试——合并到单元测试中。”
• 缺口 — “service.ts:42 的错误分支没有测试覆盖——请添加测试。”
• 噪声 — “test_keys.py 断言 format_key(x) == f'prefix:{x}'，而实现返回 f'prefix:{x}'——删除此测试；调用方的测试已覆盖任何故障。”参见 reference/test-design-rules.md。

接口

Failure { status: FAIL category: YOUR_CHANGE | OUTDATED_TEST | TEST_BUG | NOISE_TEST | MISSING_DEP | ENVIRONMENT | CODE_BUG test: string // 测试名称 location: string // 文件:行号 error: string // 单行错误消息 action: string // 将采取的修复措施（修复 / 删除 / 升级处理） }

State { target = $ARGUMENTS runner: string // 发现的测试运行器 command: string // 准确的测试命令 mode: Standard | Agent Team baseline?: string failures: Failure[] costSignals?: { // 发现阶段可用时填充 runtimePerCategory: map<string, duration> mockDensity: map<file, count> // 每个测试文件中 mock/Mock/stub/spy 的匹配次数 testToSourceRatio: map<dir, float> // 每个目录的测试_LOC / 源码_LOC } }

约束

始终：

• 运行任何操作之前，先发现测试基础设施——阅读 reference/discovery-protocol.md。
• 每次修复后都重新运行完整测试套件，确认没有回归。
• 解决每一个失败的测试——修复、删除（如果是噪声测试）或升级处理。遵循所有权要求。
• 尊重测试意图——修复前先了解测试失败的原因。应用 reference/test-design-rules.md，判断测试锁定的是行为还是实现。
• 正确性比速度更重要——修复前先了解测试失败的原因。
• 套件健康状况是交付成果——通过且能提供有效信号的测试套件是每项任务的一部分，不可有可无。
• 对整个测试套件的健康状况负责——你修改了代码库，就要对其负责。
• 执行所有已发现的测试类别——单元测试、集成测试和 E2E 测试。每个类别都可能有自己的运行器和命令。发现并运行每一类测试。
• 根据 MECES 评估测试覆盖率——在最终报告中标出重复测试、覆盖缺口和噪声测试。

绝不：

• 运行或管理 scenarios/ 目录中的场景——这些是由 implement 技能的工厂循环管理的留存评估集，不属于测试套件。
• 说“预先存在”“不是我改的”或“本来就坏了”——参见所有权要求。
• 把失败的测试留给用户处理。
• 将失败的测试套件作为交付成果。
• 在有完整测试套件可用时运行部分测试套件。
• 应用修复后跳过测试验证。
• 修复一个测试导致另一个测试失败时回退并放弃——找到根本原因。
• 创建新文件来规避测试问题——修复实际问题。
• 为了让测试通过而弱化测试——尊重测试意图并确保行为正确。（对应原则：不要默认认定所有现有测试都是正确的。应用 reference/test-design-rules.md——锁定实现细节、重述框架契约或只验证调用顺序的测试应删除，不应通过迁移来保留。）
• 概述或猜测测试输出——逐字报告实际输出。
• 跳过或悄悄省略 E2E 测试——如果存在 E2E 测试，就必须执行。如果需要先进行设置（安装浏览器、启动服务），应说明具体情况并升级处理，不能悄悄跳过。

参考资料

• reference/discovery-protocol.md — 运行器识别、测试文件模式、质量检查命令、成本信号（运行时长、模拟对象密度、测试与源码的比例）
• reference/output-format.md — 报告类型、失败类别、MECES 评估
• reference/test-design-rules.md — 与语言无关的规则：哪些内容值得测试、模拟对象与伪实现、结果与调用顺序，以及何时应删除测试
• reference/failure-investigation.md — 失败类别（包括 NOISE_TEST）、修复流程、升级处理规则、所有权相关措辞
• examples/output-example.md — 六种报告类型的具体示例

工作流

1. 发现

阅读 reference/discovery-protocol.md。

match (target) { "all" | empty => 完整测试套件发现 file path => 针对性发现（仍须先识别运行器） "baseline" => 仅发现并采集基线，不做修复 "audit" => 仅发现、采集成本信号并进行设计审查，不运行测试 }

阅读 reference/output-format.md，并据此呈现发现结果。

2. 选择模式

如果 target == "audit"：跳过模式选择，转到第 7 步（审计）。

AskUserQuestion： Standard（默认）— 顺序执行测试，按发现、运行、修复、验证的流程进行 Agent Team — 按测试类别（单元测试、集成测试、E2E 测试、质量检查）并行运行

在以下情况下推荐使用 Agent Team： 测试类别不少于 3 种 | 完整测试套件运行时间超过 2 分钟 | 失败涉及多个模块 | 需要修复 lint/typecheck 错误和测试失败

3. 获取基线

运行步骤 1 中发现的所有测试命令，不只是主要测试套件。如果单元测试使用 vitest，而端到端测试使用 playwright，则必须运行这两个命令。记录各类别的通过、失败和跳过数量。

阅读 reference/output-format.md，并据此呈现基线。

match (baseline) { all passing => 继续 failures => 按照 Ownership Mandate 标记——这些问题仍由你负责 E2E skipped => 说明跳过原因并上报——绝不可悄然省略 }

4. 执行测试

match (mode) { Standard => 依次运行发现的每个测试命令（单元测试 → 集成测试 → E2E），捕获详细输出并解析结果 Agent Team => 创建团队，为每个测试类别启动一个执行器并分配任务——E2E 需要专属执行器 }

E2E 执行清单：

• 确认已安装 E2E 执行器（如有需要，运行 npx playwright install）
• 使用 E2E 专用命令运行测试——不要假设单元测试命令也涵盖 E2E
• 如果 E2E 需要运行服务（开发服务器、数据库），请启动这些服务，或具体说明原因并上报
• 在输出中单独报告 E2E 结果

阅读 reference/output-format.md，并据此呈现执行结果。

match (results) { all passing => 跳至步骤 5 failures => 继续修复失败 E2E not run => 这是失败——返回并运行 E2E，或说明原因并上报 }

对于每项失败：

1. 阅读 reference/failure-investigation.md，并对失败进行分类。
2. 如果类别 == NOISE_TEST：应用 reference/test-design-rules.md，确认测试锁定的是实现、框架或调用顺序，而非行为；删除该测试，并确认其他地方已覆盖该行为，或该行为无需显式测试。
3. 否则：对代码或测试进行最小限度的修复。
4. 重新运行相应测试以验证。
5. 重新运行完整测试套件以确认没有引入回归。
6. 如果修复某项测试导致另一项测试失败：找出根本原因，不要放弃。

5. 运行质量检查

对于步骤 1 中发现的每项质量检查命令：

1. 运行该命令。
2. 如果通过：继续。
3. 如果失败：修复你修改过的文件中的问题，然后重新运行以验证。

6. 报告

阅读 reference/output-format.md，并据此呈现最终报告。

最终报告必须包括：

• 类别覆盖情况——确认已运行每个发现的类别（单元测试、集成测试、E2E），并列出各类别的数量
• MECES 评估——标记执行期间发现的重叠测试、覆盖缺口和噪声测试（同义反复测试、重新验证框架行为的测试、身份映射 mock、仅断言调用顺序的测试、mock 协作者的仓库测试）。应用 reference/test-design-rules.md。
• 如果未执行 E2E 测试，报告必须说明原因以及运行所需的条件——绝不可悄然省略

7. 审计（当 target == "audit" 时）

应用 reference/test-design-rules.md 和 reference/discovery-protocol.md 中的成本信号捕获规则。不要运行测试。生成审计报告（参见 reference/output-format.md），列出：

1. 同义反复候选项——镜像琐碎实现的测试文件（文件:行号、源代码:行号、原因）
2. 重新验证框架行为——断言 schema/ORM/router 执行其声明功能的测试
3. mock 协作者的仓库测试——数据访问客户端被 mock 且没有执行真实查询的仓库测试
4. 身份映射服务测试——断言仅证明 mock 返回了预先告知它的内容的服务测试
5. 仅断言调用顺序的测试——主要断言是 mock.assert_called_with(...)，且没有结果检查的测试
6. 成本热图——按目录列出测试与源代码的比例、mock 密度及运行时（如有）
7. 建议删除和重构的内容——列出具体文件及理由；估算总代码行数（LOC）和测试用例缩减量

审计模式绝不修改代码。它只生成报告，供用户在删除后通过 /start:test all 执行，或在单独的重构会话中处理。

与其他技能集成

由其他工作流技能调用：

• 在 /start:implement 之后——验证实现没有导致测试失败
• 在 /start:refactor 之后——验证重构保留了原有行为
• 在 /start:debug 之后——验证修复解决了问题且没有引入回归
• 在 /start:review 之前——确保审查前测试套件通过

由其他技能调用时，如果已识别测试基础设施，则跳过步骤 1。