测试审计
此技能有两种模式：
- 创作模式。 以下创作门禁适用于您添加或更改的每个测试。
- 审计模式。 按生产所有者分组，以连贯的批次移除低价值证明。切勿追求删除数量；目标是让每个契约有一个强主，而不是减少数量。
对于一次性精简整个子系统测试面的活动，请先阅读CAMPAIGN.md。
创作门禁
在添加测试之前，回答这四个问题：
- 它保护哪些可观察行为、不变量或独立契约？
- 哪些可信的回归会导致它失败？
- 为什么现有证明遗漏了它？每个契约应有一个在最强边界处的主要所有者。位于另一层的测试需要不同的传输或生命周期风险来证明其必要性。应扩展现有表格和共享夹具，而不是添加近似副本，并合并重复的设置。
- 它是否需要没有生产调用者的导出、标志、包装器或注入钩子？如果需要，请将证明移至真实边界。
支持规则：
- 使用边界和成本指南来选择测试所处的位置及其可能成本。
- 回归测试必须在修复前因预期原因失败，并在修复后通过。如果您无法展示修复前的失败，请在报告中说明。
- 在所属边界的一次回归即可覆盖一个缺陷。切勿在缺陷经过的每一层都重放它。
- 保持行为不变的重构不应破坏测试。
垃圾模式
- 拒绝自我比较、复制清单、源代码搜索、实现或调用形状断言、重复契约、仅测试用生产缝隙、由被测对象生成的预期值，以及提供被断言行为的模拟对象。
- 夹具不得伪造所有者本应产生的收据或排序，不得声称能够持久化代码从未写入的路径。
- 阴性对照必须在预期守卫处失败，测试名称必须匹配其实际执行的行为。
- 审计候选时，请使用完整检查清单。
保留标准
- 保留保护独立契约的测试：公有API、SDK、协议、配置、迁移、存储、安全、平台、默认值、提示字节、生成的跨语言输出、打包、发布、架构和可观察排序。即使是静态或慢速的测试，也不可随意丢弃。
- 仅当源代码检查能经受仅标识符的重构且保护独立的面向用户的契约时，才可接受。
- 失败的基线测试可能是需要修复的产品缺陷，而不是要删除的测试。
审计与验证
- 在任何审计编辑之前，请阅读候选证据和工作流。检查完整的所有者、调用者和历史记录，并在删除任何内容之前记录保留的证明。
- 删除过时的生产缝隙及其测试。切勿优化删除数量。
- 在测试运行进行中时，不要编辑检出的代码。先运行项目针对该所有者及其同级测试的聚焦测试命令，然后运行项目的已更改文件检查，最后在提交前获取审核。
- 报告原因、保留的契约、证明及其成本、生产代码与测试代码变更的行数，以及后续行动。仅当任务授予您该权限时，才进行提交、推送或落地。