用变异测试验收 AI 修复的测试代码

AI 把一条反复失败的测试修绿了，究竟修好了异步时序，还是删掉了最有价值的断言？这篇文章提出一个 90 分钟的小实验：先记录失败率，再让助手修改，最后故意破坏业务实现，看测试还能不能报警。

最值得带走的结论是：流水线变绿，只能证明测试通过；主动制造错误后测试会失败，才能说明它仍在保护某项行为。 不过，原文提供的是实验方案和示意脚本，没有展示真实仓库的验证结果。

先写下什么算成功，再让 AI 动手

原文从一个发票金额舍入问题切入：CI 每周两次被同一条异步测试卡住，团队习惯重跑。后来 AI 让测试通过，三周后舍入错误却上线了，因为修复时悄悄删掉了相关断言。

作者明确说明，这个故事由常见失败模式拼成，并非某家公司的事故记录。它用于解释风险，不能当作实测案例引用。

问题出在任务目标上。「让红色测试通过」允许很多操作：延长超时、给断言套重试、跳过用例，甚至删除比较金额的代码。其中一些操作可能合理，也可能只是把报警器关掉。单看绿色结果，分辨不出来。

作者因此要求，在碰仓库之前写下可被推翻的假设：给助手失败测试和 CI 输出的最后 200 行，它能否完成一项修复，同时满足连续运行 20 次通过，以及底层行为被故意破坏后测试仍会失败？

实验必须提前确定通过条件、终止条件和检查时间。看完 AI 的修改再制定标准，很容易把「验证方案」变成「替已有结果找理由」。

这里的 spike，就是一次限时技术探索：只验证一个假设，到点作出决定。它的交付物是证据和判断，不是一份看起来完整的修复。

连跑 20 次，与故意改坏一次，分别验证什么

实验放在可丢弃的 git worktree 中，避免干扰现有工作分支。示例通过 git worktree add "../spike-$TASK" -b "spike/$TASK" "$BASE" 创建工作区，TASK 默认是 flaky-invoice-test，BASE 默认是 main，REPS 默认是 20，并记录实际经过的时间。

第一步先测基线。下面这段保留原文代码，用于统计指定测试在修改前失败了多少次：

sample() {                      # sample <label> <runs> <cmd...>
  local label="$1" runs="$2" fails=0 i; shift 2
  for ((i = 1; i <= runs; i++)); do
    "$@" >/dev/null 2>&1 || fails=$((fails + 1))
  done
  log "$label: $fails/$runs failed"
  SAMPLE_FAILS=$fails
}

sample baseline "$REPS" npm test -- --runInBand -t "invoice total"
log "baseline captured; hand off to the assistant now"

要看清最后的执行命令：它针对 JavaScript 项目中的 Jest，使用 --runInBand 和 -t "invoice total" 筛选、执行测试。sample 会丢弃标准输出和错误输出，所以失败日志需要另外保留，不能指望这个计数函数完成诊断。

第二步是变异测试（mutation testing）：人为往生产代码中植入一个错误，再检查测试能否发现。原文的变异很具体，把发票计算中的 return roundToCents(total); 改成 return total;，故意取消金额舍入。

下面是原文判断变异是否被发现、恢复代码并复测的逻辑，前提是准备好 /tmp/mutation.patch：

git apply /tmp/mutation.patch
if npm test -- --runInBand -t "invoice total" >/dev/null 2>&1; then
  log "MUTATION SURVIVED - the test no longer pins the behaviour"
  VERDICT=KILL
else
  log "mutation killed - the assertion still has teeth"
  VERDICT=CANDIDATE
fi
git checkout -- src/invoice.js

sample after "$REPS" npm test -- --runInBand -t "invoice total"
[ "$SAMPLE_FAILS" -eq 0 ] && [ "$VERDICT" = CANDIDATE ] && VERDICT=SHIP
log "verdict: $VERDICT"

重点是 if npm test ...：取消舍入后测试仍然通过，变异就「存活」了，方案应被否决；测试失败，才进入候选状态。恢复实现后，还要完成重复运行，才能得到 SHIP。

两个探针各管一件事：重复运行观察稳定性，变异检查测试是否还能识别指定错误。任何一个都不能替代另一个。

90 分钟如何收口，证据又能支持到哪一步

作者把时间分为三段：前 30 分钟采样基线、读懂失败输出，明确测试保护什么；中间 40 分钟交给助手修改，最多追加一次提示；最后 20 分钟执行变异、重复采样，并写出结论。

限制追问次数有实际意义。无限修改直到通过，测到的就掺入了大量人工引导和重试成本，难以判断这套方法是否值得推广。

最终应留下决策表，逐项记录通过与终止条件。文章没有展示一份已经填好的实验记录，也没有给出真实耗时或修复成功率。

作者还给连续 20 次通过划了边界：在相应统计假设下，95% 置信水平对应的失败率上界仍约为 15%。实际理解时还要考虑每次运行是否独立、环境是否稳定。20 次全绿，远远不等于消除了偶发失败。

原文认为，20 次采样能粗略区分 5% 与 50% 的失败率。但对低频问题，这个样本很容易一次都碰不到。因此，它适合快速筛查，不能替代持续观察。

免费模型和免费服务器只是降低实验成本的选项。文章披露自己属于 MonkeyCode 的产品推广，免费额度与可用情况来自运营方，需要另行确认。这里没有可供验证的具体额度，也没有模型对比结果。

我的判断

我认可它把审查重点从「有没有变绿」推进到「还能不能抓住错误」。相比只看 diff、只重跑 CI，这一步能提供更直接的行为证据，尤其适合检查 AI 是否弱化了关键断言。

但一个变异被杀死，只能证明测试发现了这一次人为错误。 它不能证明整条测试足够强，更不能证明其他业务边界都被覆盖。还要确认失败确实来自预期断言，而不是依赖异常、环境故障或原有的随机失败。

脚本也不能直接当成可运行工具。原文已经声明它只是示意，未在读者仓库执行；其中补丁的 @@ 没有标准行号范围，需要生成有效 diff。git checkout -- src/invoice.js 还会丢弃该文件未暂存的修改，如果助手也改过生产代码，就可能把修复一起撤掉。日志记录了经过时间，却没有自动强制执行三个检查点。

适用前提同样明确：测试主要因时序或顺序不稳定，业务规格清楚，实现没有另一个待修正的问题。重外部依赖、缺少可单独改动的行为边界，或者每轮测试耗时很长，都需要调整探针与预算。

这是一套有用的评审思路，但「90 分钟足够」仍是作者的经验判断，原文没有对照实验为它背书。

能拿来做什么

• 从 Jest 中挑一条长期偶发失败、运行较快的测试，先记录失败次数和失败日志，再把测试与 CI 最后 200 行交给助手，明确要求保留它保护的业务行为。
• 审查 AI 修改时，为关键断言设计一个最小错误，例如取消金额舍入；确认测试因预期断言失败，再恢复实现并复测。
• 按测试耗时安排重复次数；无法完成 20 次时，如实记录样本更少、结论更弱，不要把少量全绿写成问题已经消失。
• 在独立 worktree 中保留修改前后的证据，并按代码保密要求选择基础设施；涉及受监管、客户机密或未发布代码时，按原文建议使用自己控制的环境。