用途：判断一次变更“欠”哪些测试，覆盖功能、缺陷修复、重构及任何行为变化，也用于评审 diff 的测试是否足够。需以 principal-engineering 技能为背景，测试手艺本身另见 writing-unit-tests。
主要能力：行为变化必须在同一变更内更新测试，空的测试 diff 应视为评审问题；纯重构的证明相反，即既有测试不改仍通过。修缺陷须附带回归测试，按失败模式而非工单命名，并展示两半证据：未修复代码下变红、修复后变绿；从未变红的回归测试只证明能编译。场景要具体并覆盖浮现出的边界，风险在失败路径时测试失败路径。每个任务带可单独运行的定向验证命令。断言必须能区分：让代码坏一次确认变红再恢复。关键路径上需对账的聚合数据要有不变量测试，断言对账本身一致。红测试规则：自己门禁中的红测试必须修复，不能靠弱化断言、删除或跳过掩盖；仅当测试断言的是旧的错误行为时才可改，且需明确说明；先归因再修复，“先前就存在”只是脚注不能当借口。不欠的测试：不可达边界、框架内部或生成代码的测试。是否先写测试属工作流问题，本技能只管发布时必须存在什么。常见错误：认为太小不必测、只测修复不先复现缺陷、凭感觉算覆盖率、加永远不会失败的断言（与有意钉住旧新行为以防过度修正的 pinning test 不同）。