用三个Git Worktree揪出被弱化的测试

补丁通过了CI，diff读起来干净利落，review只花九十秒。六周后，分页回归从当初被放松的断言守卫的那条代码路径溜了过去。这不是某个具体事故，而是一个可以复现的场景。

绿色测试套件为何证明力不足

一个通过的测试套件只回答了一个很窄的问题：已有的断言没有失败。它没有说明断言是否足够严格，也没有说明新测试在未修复的代码上是否同样会通过。审查者通常用注意力来弥补这个缺口，而注意力恰恰是周五下午最先耗尽的资源。

原文提出用三个廉价信号补回缺失的信息：新测试在基线上是否失败；移除修复但保留测试时套件是否失败；补丁删除或放松了多少条断言。

每个补丁都该经历的三重状态

每个状态都是一个detached的Git worktree，不用切分支，也没有stash风险：

1. 基线态：上游tip加上贡献者的测试改动。新测试必须在这里失败，且失败原因必须是预期的那个。
2. 补丁态：应用贡献者的完整diff。套件必须通过。
3. 变异态：补丁树上把src/回退到基线、测试原样保留。套件必须失败，否则测试根本没有观测到修复。

第三个状态是大多数review流程跳过的那一个，也是唯一能识别出"描述修复"而非"约束修复"的测试的状态。

Git worktree 是 Git 2.5 引入的命令，允许同一个仓库同时检出多个工作树到不同目录。每个 worktree 独立指向不同的分支或提交（通常是 detached HEAD 状态），共享同一个 .git 对象库。与 git stash 或频繁切分支相比，worktree 的核心优势是：无需暂存未提交的更改，无需中断当前工作状态，就能并行检查多个提交的代码。在本文的三态检查中，三个 worktree 分别对应基线、补丁和变异状态，彼此隔离，测试运行时不会相互干扰。销毁 worktree 只需 git worktree remove 或直接删除目录后 git worktree prune，非常适合“用完即弃”的审查场景。

变异测试（mutation testing） 是一种评估测试套件有效性的方法：人为向代码中注入缺陷（变异），然后运行测试，检查测试是否能检测到这些缺陷。如果测试在变异体上仍然通过，说明测试没有真正约束代码行为。本文的“变异态”是变异测试的一种轻量特例：不是注入随机变异，而是直接回退整个修复（src/ 回到基线），保留测试不变。这相当于构造了一个“已知存在 bug”的变异体，如果测试套件无法发现它，就证明新测试没有观测到修复。与传统变异测试工具（如 PIT、mutmut）相比，这种方法计算成本极低（只运行一次套件），但只能验证“修复是否被测试约束”，不能全面评估测试套件的整体强度。

搭建一个十分钟可复现的夹具

夹具刻意做小：一个模块、一个测试文件、一个bug。bug是缺少向上取整除法，任何总量小于页大小的情况都会返回零页。

mkdir tamper-demo && cd tamper-demo
git init -q
mkdir -p src tests bin

基线的src/paging.py只有一行total // size。基线测试包含三个用例：整除、大总量、零总量。随后创建一个补丁分支，修复除法、新增第四个测试，并把两个已有断言改成更宽松的>=比较。新增的测试用的是pages(10, 5) == 2——它在有bug的代码上也能通过，因此什么也没捕获。

三态检查脚本的骨架

脚本假设已安装pytest，且src/是唯一承载修复的目录。核心逻辑是三个worktree加三段判定：

git worktree add -q --detach "$WORK/base"    "$BASE_REF"
git worktree add -q --detach "$WORK/patched" "$PATCH_REF"
git worktree add -q --detach "$WORK/mutant"  "$PATCH_REF"
git -C "$WORK/mutant" checkout -q "$BASE_REF" -- src/

基线态若全绿，打印"WARN base is green; the failing reproduction is missing"；补丁态若有失败，标记FAIL；变异态若无失败，说明测试什么也没观测到，标记FAIL。最后再用git diff -U0统计测试文件里新增和删除的assert行数，删除数大于零时提示先读测试diff。

git checkout <commit> -- <path> 是 Git 中一个容易混淆的命令形式：它从指定提交中取出路径内容，覆盖工作树和暂存区中的对应文件，但不会移动 HEAD。在本文脚本中，git -C "$WORK/mutant" checkout -q "$BASE_REF" -- src/ 的作用是：在变异态 worktree 中，把 src/ 目录恢复成基线版本，同时保持测试文件和其他文件不变。这正好构造出“修复被回退、测试保留”的状态。需要注意的是，该命令会直接修改工作树文件，如果之后想恢复补丁状态，需要再次 checkout 回补丁提交或使用 git checkout -- .。这种用法比 git revert 更轻量，因为它不产生新提交，也不影响分支历史。

像审查者一样读输出

在夹具上运行脚本，报告大致如下：

== state 1: base (main) ==
1 failed, 3 passed in 0.11s
== state 2: patched (patch) ==
4 passed in 0.09s
== state 3: mutant (fix reverted, tests kept) ==
4 passed in 0.09s
FAIL the suite passes without the fix; the tests observe nothing
== assertion churn ==
assertions added=1 removed=2
REVIEW the test diff first: 2 assertion line(s) removed

两个独立信号指向同一个弱点：变异运行证明新测试无法区分修复与破坏，churn计数显示两条既有保证被削弱。单独任何一个都不足以定论，合在一起就足以支撑"请求修改"而非"批准"。

失败信息本身和失败同样重要。变异运行如果失败在导入错误上，对断言什么都没证明，日志里必须看到AssertionError或具体的测试名才算数。

免费模型能帮什么，不能帮什么

原文把分工划得很清楚。模型适合做文本形态、低风险的部分：把失败的变异日志改写成两句PR评论、从diff草拟缺失的测试、命名补丁改变的可观测行为、列出重构合理触及的既有断言。维护者独占的判断则是：被弱化的断言是否正当、套件是flaky还是真的错、以及是否合并。

一个把模型限制在边界内的prompt骨架：给定unified diff、基线日志、补丁日志和变异日志，不要求合并决策；列出diff改变的可观测行为；对每个新测试说明去掉diff后是否会失败；提出一个在变异态会失败的额外测试；无法从日志判断的标记为unknown。

原文在此处披露了与MonkeyCode的关联：文章属于其产品推广的一部分，免费模型接入和免费服务器选项的容量与条款由运营方提供、可能变化。可丢弃主机在这里是实打实的便利——三个worktree加virtualenv加测试缓存积累得很快，跑完就销毁让"从干净状态开始"成为默认而非负担，只把报告日志拷回来也让审查产物保持小而可审计。

补丁分诊决策表

信号	合并	询问作者	阻止
新测试基线失败、补丁通过、变异失败	是	—	—
变异态通过	—	—	是
有断言行被删除	—	是，要求书面理由	—
测试文件超过diff的30%	—	是	—
基线态已经全绿	—	是，复现缺失	—

这张表的价值在于把脚本输出转成可重复的第一反应，这比任何单次判定都重要。

局限与失效模式

变异运行只是一种启发式，它会以可预期的方式退化。回退src/可能破坏导入，变异失败可能源自被测断言之外；对mock或日志字符串断言的套件即使在行为改变时也常常保持绿色；flaky测试让第三态充满噪声，需要重试策略才能信任信号；大型monorepo需要受影响测试选择，这会缩小变异运行的覆盖到被选子集；合法重命名或重构测试的补丁会触发churn计数器，需要人工阅读。

Flaky 测试（不稳定性测试） 是指同一代码在相同环境下多次运行，结果时通过时失败的测试。常见原因包括：依赖时间或时区、依赖随机数、依赖网络或外部服务、测试间共享状态未清理、并发竞争等。在变异态检查中，flaky 测试会制造噪声：即使修复确实被测试约束，变异运行也可能因为 flaky 失败而被误判为“测试有效”；反之，如果 flaky 测试恰好通过，也可能掩盖测试无约束力的事实。原文建议“需要重试策略才能信任信号”，通常做法是对变异态运行多次（例如 3 次），只有全部失败才认定为有效信号。更根本的解决方式是先隔离并修复 flaky 测试，再将其纳入三态流程，否则整个检查的可信度会持续衰减。

谁应该跳过这套流程

没有可用测试命令的仓库不该从这里开始，脚本只会放大一个已经存在的套件。把测试当文档而非约束的团队会发现第三态永远是红的，一周内就会把它关掉。一个月只review一个小补丁的维护者，认真读测试diff比维护三个worktree和一个shell脚本更有价值。这套流程的收益出现在补丁量超出审查者注意力、且被弱化的断言发现得越晚代价越高的仓库里。三个worktree、一个脚本、一个日志文件，足以让这项检查变成例行公事。