test-audit

测试审计

测试的价值在于捕获其他手段都捕获不到的可信回归。Agent 会为每个小改动编写测试，而其中大多数只是再次验证源码、通过 mock 重放更强的测试，或固定私有调用形式。删除这些测试后，覆盖率几乎不会下降，维护成本和测试套件耗时却会降低。

• **是：**全面检查某个目录，找出低价值、位置不当和已跳过的测试；也可以对整个子系统或仓库开展精简行动，在保持覆盖率的同时达到明确目标，并删除这些测试一直维系的、仅供测试使用的生产代码接口。
• **不是：**在测试合入前进行把关或审查功能差异（tidy）、通过拆分或分片来加速 CI（ci-speedup），或为尚未测试的代码编写测试。

选择模式

模式	适用场景	完成标准
Audit	针对指定文件或目录进行集中检查	找出少量高置信度候选项，提供完整证据，并在一次连贯的批量删除中完成删除，且验证通过
Campaign	涵盖某个子系统或仓库的全部测试，或任何带有目标的请求（“删除 20%”）	达到目标，或通过清单说明为何无法达到；覆盖率保持在容差范围内，且通过保留性审查。先阅读 references/campaign.md

开始前设定目标

如果只说“清理测试”，往往删掉几个显而易见的测试后就会停下，因为每个剩余候选项单独看起来都说得过去。Audit 和 Campaign 都需要一个量化目标。用户给出了目标，就使用它；如果没有，就提出一个目标并据此继续，而不是等待：

删除 <scope> 中价值最低的 20% 测试声明，同时将行覆盖率和分支覆盖率保持在基线的 2 个百分点以内，并确保所有保留的测试通过。

先测量基线（references/coverage.md），然后按价值从低到高持续删除，直到达到目标或用尽覆盖率预算。只有清单表明每个剩余候选项都保障着一项明确契约时，提前停止才算合理。目标是努力程度的下限，并不意味着可以删除存疑的测试：下文的保留标准优先于数量。

垃圾模式

审计或精简行动要找出以下问题：

• 不含断言、只用于探测覆盖率的测试；以及在不可能抛出异常的路径上唯一断言为“不会抛出异常”的测试
• 自我比较、恒等复制，以及由被测辅助函数或渲染器生成的预期值
• 被复制的 fixture、清单、manifest、导出列表或数据快照，而测试本身也定义了这些数据
• 精确匹配源码、导入语句或字符串的 grep：重命名就会失败，真实行为变化却仍能通过
• 对私有谓词或调用形式的测试（对内部函数使用 toHaveBeenCalledWith），而真实边界处已重复验证相同内容
• 对同一契约的重复调用，以及对共享辅助函数按提供方逐一重放
• 唯一目的在于维系仅供测试使用的导出项、全局变量或包装器的测试；以及唯一调用方是测试的生产代码
• 实现了被断言行为的 mock，或一个 mock 代替了多个不同的 API
• fixture 提供了被测代码本应生成的顺序、回执或回调；或代码路径从未写入某个存储，却断言数据已持久化
• 只复述已声明标志，而不验证该标志所承诺行为的能力测试
• 因无关原因而通过的否定控制，例如被另一项防护逻辑拒绝
• 名称承诺的内容超出断言实际检查的范围：应依据断言而非标题判断测试

放错位置和跳过的测试

另外两种发现类型。仅凭这一点，它们都不符合删除条件；移动测试或取消跳过，都不算朝目标推进的删除。

• **放错位置：**测试位于某个所有者的测试套件中，却只测试另一个所有者，例如 routes/posts.test.ts 中的 slug 格式检查，完全没有触及路由，只调用了 lib/slug.ts。将它移到规范所有者的测试套件中，保留回归测试时按“编辑方式”所述处理。
• **跳过：**测试已禁用，例如 it.skip('prorates refunds on downgrade')、xit、@pytest.mark.skip 或 t.Skip()。先取消跳过并运行；切勿一看到就删除。如果通过，就保持启用，并像评估其他测试一样评估它。如果失败，就按保留标准将其视为可能的产品缺陷：复现问题并修复所有者。如果跳过条件有真实的平台或环境原因，则不算发现。

保留标准

如果测试独立地验证了公共 API、协议、配置、迁移、存储、安全、平台、默认值、生成的跨语言代码、软件包、发布或架构契约，就应保留。此外，还应保留：

• 调用顺序可观察为行为时，对调用顺序的测试
• 具有可信失败模式的回归测试
• 当面向用户的键、字节或路径发生变化时会失败，并且在仅重命名标识符后仍能保留作用的源代码检查；如果这是成本最低的独立保障，就应保留
• 基线版本上会失败的保留测试：将其视为可能的产品缺陷，复现问题并修复所有者，而不是删除测试

静态或缓慢都不是删除理由。看起来像是在测试实现的测试，仍可能是某个契约唯一的证明；删除前应证明并非如此。

每个候选项的证据

评估前，请阅读完整测试、生产代码所有者、其调用方和被调用方、同级实现、重叠测试，以及解释该测试存在原因的历史记录。每项删除都要记录：

• 测试名称和位置，以及它实际能够检测到的失败
• 调用其覆盖的接口的非测试调用方
• 仍然存在的更强证明（注明保留的测试名称），或不存在任何契约的原因
• 删除后得以移除的生产代码或测试支持代码
• 删除该测试后的覆盖率变化（如有测量）

缺少任何一项信息，都说明候选项尚未准备就绪。宁可删除少数把握较大的测试，也不要列出一长串推测性候选项；不要为了达到数量而把不确定的候选项变成删除项。

编辑方式

按所有者边界成批删除连贯的测试。每批删除测试时，同时删除因此不再需要的仅供测试使用的导出项、全局变量、包装器、重置钩子和失效的生产代码路径，而不是保留别名。将保留的回归测试移到其规范所有者处，并把重复的初始化代码合并到共享夹具中。目标是生产代码行数和测试代码行数都净减少。不要添加仅复述相同实现的替代测试。

验证

1. 每批都运行所有者和同级测试。
2. 如果删除的测试通过 grep 源代码或断言计划来验证行为，就运行负责真正契约的脚本或试运行。
3. 使用与基线相同的命令重新测量覆盖率，并按文件与预算比较。
4. 报告 git diff --numstat，并分别统计生产代码和工具代码行数，以及测试代码行数。

权限

在本地运行测试和覆盖率，以及在工作树中删除测试和仅供测试使用的接口，都是任务的一部分：直接执行，无需询问。只有在用户要求时才提交、推送或创建 PR。符合保留标准的测试必须保留；即便如此仍要删除测试，应由用户决定；更改覆盖率阈值或 CI 门禁也同样由用户决定。

交接

• 目标、基线和最终数据：声明或代码行数，以及行覆盖率和分支覆盖率
• 删除的类别及其根本原因（是什么导致这些测试不断出现）
• 生产代码简化情况，与测试代码行数分开统计
• 保留的误报项及每项保留的原因
• 实际运行的验证及结果
• 为仓库的 AGENTS.md 提出的门禁建议，依据本次审计实际发现的模式制定，以防 Agent 编写这类测试

注意事项

• 删除某条路径上唯一断言的测试后，行覆盖率仍可能保持不变，因为另一个测试仍会执行这些代码行，却不检查它们。如果从覆盖率看，删除似乎没有代价，请确认有保留的测试断言了相关行为，或针对负责该行为的代码运行变异测试（references/coverage.md）。
• 汇总覆盖率会掩盖某个子系统失去唯一验证的情况，因为无关区域的覆盖率可能有所提升。对于被删除测试涉及的每个生产文件，都要逐文件比较。
• 仅按唯一行覆盖率排列候选测试会删错测试：某个测试即使没有唯一覆盖行，也可能包含对这些行的唯一断言。唯一覆盖率只能让测试成为候选；指定保留哪个测试，才能决定删除哪个测试。
• 在同一检出目录中，Vitest 或 Jest 以监视模式运行时编辑测试，会导致半编辑状态的文件被重新运行，失败看起来像是删除测试引发的回归。批量操作前请停止监视器。

参考文件

文件	适用时机
references/campaign.md	运行 Campaign 模式，或按目标删减超过一个目录的测试时
references/coverage.md	测量基线、逐文件和逐测试覆盖率、预算检查以及变异抽查时

仅用于维护：evals/evals.json 保存用于修改此技能的场景和路由提示词；任务期间不会加载。

相关技能

• tidy：在差异中新增或修改测试时立即对其进行检查，并同时审查差异的其余部分。此技能只会清理现有测试套件，或按 Campaign 模式删减测试；“审查我的 PR 中的这些测试”应路由到 tidy，而不是此技能。

致谢

改编自 OpenClaw 的 test-audit 技能（openclaw/openclaw，MIT）。来源信息记录在代码仓库的维护说明中。