行为变更时确定测试义务：用回归测试、可区分断言和…

当功能、缺陷修复、重构或任何行为变更需要决定该补哪些测试，或评审 diff 的测试是否充分时使用；需以 principal-engineering 为背景，测试技艺见 writing-unit-tests，本技能只判断变更欠哪些测试。

适用场景

解决思路

1. 把测试当作关于行为的可执行声明：行为变更若不改测试，就是没人写下的声明；用两种失败模式反查——绿色套件覆盖了不可能工作的代码，或测试/gate 从未运行。
2. 让测试随行为在同一变更中改变：行为变更若测试 diff 为空，应作为评审问题而非风格偏好；纯重构则要求现有测试不加修改仍通过，这正是重构成立的条件。
3. 缺陷修复必须交付回归测试：按失败模式命名，而不是按工单编号命名；作者展示两半证据——在未修复代码上为红，在修复后为绿；从未变红的回归测试只能证明它能编译。
4. 测试场景要具体，并纳入 grounding 和 review 浮现的边缘情况：把这些边缘情况按名称写入测试；只测 happy path 只测试演示，不测试本次变更。
5. 当变更风险在失败路径时，为失败路径写测试：按 handling-failures，要求失败被记录且类型化，这种 surfaced 行为是测试应负责的行为。
6. 每个任务都带上针对性的 verify 命令：任务中写明能证明本次变更的 verify 命令，可单独运行，并写在 reviewer 能运行的位置；“套件通过了”不能为套件从未覆盖的内容背书。
7. 断言必须可区分：先破坏代码一次，确认测试变红，再恢复；无论代码是否改变都通过的测试不能证明任何事，不可区分的断言会让套件在行为损坏时仍保持绿色。
8. 必须对账的聚合数据要有不变量测试：项目声明关键路径上任何求和、派生或镜像其他数据的内容，不能只写点状示例；测试要断言对账本身（conservation pattern），即聚合值等于原始记录所蕴含的结果。
9. 对红测试执行修复规则：你负责的 gate 中的红测试要修复，绝不静音；为交付而弱化断言、删除测试或标记 skipped，等于把已检测到的缺陷变成未检测到的缺陷。
10. 只有测试断言的是旧的、错误的行为时，才可合法修改测试，并且变更要明确说明这一点。
11. 先归因来源，然后无论测试是谁的都要修复；“预先存在”只是脚注，绝不是借口（见 verifying-before-done）。
12. 遇到“太小不需要测试”时，核对一行改动是否触达没有测试覆盖的行为；若触达，就补测试，否则回归会一直沉默到有人审计。
13. 修复缺陷时先复现缺陷，再测试修复；只测修复而不复现缺陷会漏掉 red-before-green 这一半证据，而这一半才证明测试能看见缺陷。
14. 按行为计数覆盖率：把变更的行为逐项列出，并对应到命名它们的测试；不要凭感觉统计覆盖率（计数规则同 technical-writer 插件 technical-writing/references/truth.md 中“Keeping documents true”的文档覆盖计数）。
15. 审查断言是否可能被合理缺陷击败；不要添加永远不针对任何东西的区分性测试，即没有任何合理缺陷能让其失败的断言。要与合法的 pinning test 区分：pinning test 故意同时通过旧代码和新代码，以保护未变的相邻行为免遭过度修正，并且它要明确声明自己的用途。

适用边界 · 注意事项

• 不为不可达边缘写测试；给不可能发生的情况加围栏是意图良好的死代码（见 scoping-changes）。
• 不测试框架内部或生成代码；应在自己拥有的边界测试对它们的使用。
• 不要求 test-first 流程；测试是否先写属于工作流，由项目安装的 test-first workflow skill 治理；本技能只治理变更发布时必须存在什么，而不论由何种顺序产生。