构建最小且可信的测试证据

保护可观察行为和重要风险，而非实现细节。目标是测试质量，不是测试数量或覆盖率百分比。若仓库的测试命令和约束更严格或更具体，应遵循它们。

从行为和风险开始

新增或修改测试前：

1. 确定要保护的独立行为、契约、不变量或已确认回归问题。
2. 确定测试能够暴露的真实缺陷或会造成明显后果的失败。
3. 先检查已有测试和静态保证，再判断是否需要新证据。
4. 选择足够真实且成本合理的稳定观察边界。
5. 选择能区分目标行为和重要失败情况的最小测试集合。

从需求、契约、已知示例、不变量或历史回归中推导预期结果，不要复述生产算法。测试是既有行为的证据，不是新需求的来源。除非仓库权威资料表明预期已改变，否则把现有测试、快照和断言视作可能的契约证据。

如果拟议测试没有保护独立的行为、契约或重要失败情形，就不要添加。

优先覆盖有价值的内容

优先覆盖：

• 已确认的验收标准和核心成功路径；
• 跨越后会改变结果的边界；
• 对产品、运行或用户有真实影响的失败路径；
• 权限、安全、隐私和数据完整性；
• 复杂业务规则和状态转换；
• 已经发生过的缺陷的回归场景。

避免测试：

• 简单访问器、直接透传，或类型和静态工具已经保证的事实；
• 项目并不拥有的框架行为；
• 可在不影响可观察行为的情况下改变的私有实现细节；
• 除非交互本身是契约，否则避免 mock 调用次数或内部顺序；
• 触发同一行为和失败机制的重复输入；
• 只为提高覆盖率而添加的、没有依据的极端场景。

控制证据集合

从行为上不同的等价类中选择代表性案例，而不是枚举输入。只有边界会改变行为时才测试边界值。参数化或表驱动案例应让同一规则保持清晰。

如果两个测试会因同一缺陷失败，且不保护不同的契约，就合并或删除其中一个。只有每个层级保护不同风险时，才在多个层级添加证据。

选择观察层级

使用成本最低、但足够有把握的层级：

• 类型、lint 规则、模式或构建能可靠证明的保证，使用静态检查。
• 对具有明确输入输出的独立业务逻辑，使用单元测试。
• 重要行为或失败发生在模块协作、持久化、序列化或基础设施边界时，使用集成测试。
• 端到端测试只保留少量关键用户旅程；不要用它枚举边缘情况。

不要为了让每个函数都有测试而创建单元测试。优先使用真实、廉价且确定的依赖。只有隔离、可控失败、确定性或成本足以证明降低真实性合理时，才使用假对象、桩或 mock。不要用大量 mock 重复已被更高真实性证据保护的内部关系。

验证并停止

运行新增或修改的聚焦测试，以及直接受影响的已有测试。只有耦合、风险或仓库规则证明成本合理时，才扩大到更广的测试套件。

把覆盖率报告用于发现可能的盲区，而非作为完成目标。不要为了百分比、简单分支或 100% 覆盖率制造低价值案例。相比更高的总数字，更应优先可信地保护核心行为和有明显后果的失败。

除非用户明确授权，否则测试应与付费或生产服务、生产数据及难以恢复的外部操作隔离。让改动始终服务于请求的行为；记录无关问题，不扩大 diff。

只询问属于用户的决定

先调查；只有现有证据无法解决以下问题时才询问：

• 规格、现有测试与当前行为互相冲突；
• 公开契约或用户可见行为发生改变；
• 安全、支付、隐私、权限或数据迁移的验收阈值或剩余风险；
• 是否删除或削弱仍可能代表有效需求的测试；
• 主要为了可测试性而做的重大生产架构改动；
• 外部影响或执行成本明显不同的测试策略。

普通的接缝、测试案例、断言、替身和局部测试重构无需另行审批。