testing-changes

测试变更

必备背景：principal-engineering 技能。测试设计归 writing-unit-tests 管；本技能规定变更必须包含哪些测试。

概述

测试是对行为声明的可执行形式。改变行为却不改测试的变更，相当于提出了一个无人记录的声明。由此会出现两种失败模式：测试套件在实际上无法工作的代码上仍然全绿，以及测试或门禁从未运行。

变更必须包含的测试

1. 行为变更时，测试也必须在同一变更中更新。 行为发生变化，但测试差异为空，这属于审查发现的问题，而非风格偏好。纯重构则需要相反的证明：现有测试未经修改仍然通过，这正是它属于重构的依据。
2. 修复 Bug 时必须附带回归测试。 测试应以故障模式命名，而不是以工单命名。作者要展示两个阶段：未修复的代码会使测试失败，修复后测试通过。回归测试从未失败过，只能证明它能编译。
3. 场景必须具体，并涵盖已显现的边界情况。 探查和审查发现的边界情况要逐一写入测试；仅测试成功路径，测试到的只是演示，而非变更本身。如果变更的风险在失败路径上，就要测试失败路径（参见 handling-failures：它要求记录带类型的失败，而这种显现行为必须由测试覆盖）。
4. 每项任务都要附上针对性的验证命令。 任务要注明能证明此变更正确的验证命令，该命令必须可以单独运行，并写明审查者在哪里可以运行它。“测试套件通过”无法为套件未覆盖的内容作证。
5. 断言必须具有区分能力。 无论变更如何，测试都能通过，就什么也证明不了。故意破坏一次代码，确认测试会失败，再恢复代码。缺乏区分能力的断言，会让测试套件在行为已损坏时仍然保持全绿。
6. 必须保持一致的汇总值要有不变量测试。 对项目声明的关键路径（参见 principal-engineering 中的风险等级）上的任何数据进行求和、推导或镜像时，测试不能只有单点示例：还要断言其自身的一致性（守恒模式），即汇总值与原始记录推导出的结果相等。

测试失败规则

你负责的门禁中，失败的测试必须修复，绝不能消音：为发布而弱化断言、删除测试或将其标记为跳过，就是把已检测到的缺陷变成未检测到的缺陷。只有当测试断言的是旧的错误行为，且变更明确说明这一点时，修改测试才是合理的。先查明问题的来源，然后无论测试归谁负责都要修复；“原本就存在”只能作为补充说明，绝不是借口（参见 verifying-before-done）。

变更不必包含的测试

• 不可到达边界的测试（参见 scoping-changes：为不可能发生的情况设防，只是带着好意编写死代码）。
• 框架内部实现或生成代码的测试。在你负责的边界处测试对它们的使用即可。
• 先写测试的流程：测试是否先写属于工作流问题（如果项目安装了测试优先工作流技能，则由该技能决定）；本技能规定变更发布时必须具备什么，无论生成这些内容的顺序如何。

常见错误

• “改动太小，不值得测试。” 一行变更也可能触及测试未覆盖的行为，导致回归问题一直悄无声息，直到有人审查它。
• 只测试修复，不复现 Bug。先失败再通过的前半部分，才能证明测试能发现缺陷。
• 凭感觉统计覆盖率。将变更的行为数量与测试中明确标出的行为逐一核对（采用与技术写作插件 technical-writing/references/truth.md 中“让文档保持真实”部分下的文档覆盖率统计相同的计数规则）。
• 添加始终无法区分行为的测试：没有任何合理缺陷能使其失败。这与合法的固定行为测试不同；后者特意在新旧代码上都通过，以防相邻行为被过度修正。固定行为测试应明确说明其用途。