我的变异测试跑出了 252/252 全杀。但每次击杀都是假的。

我用 Claude Code 构建一些小型 Python 工具来运行家里的部分系统，对于任何重要的功能，我都会让它对测试套件做变异测试：故意改坏代码，一次只制造一个小故障，然后检查是否有某个测试因此失败。如果一个变异体没有任何测试能察觉，那就说明测试有漏洞。那次看起来完美的运行：三个小时，252 个变异体，252 个全部被杀。然而我在每次长时间运行后执行的那项检查失败了。这个检查会把未修改的代码重新送入同一个运行器，按理应该通过，但它没通过。发生了什么：运行器会为每个变异体把代码和测试复制到一个全新的临时文件夹中。三天前，有一个测试开始读取一个放在代码旁边的小数据文件，但没有人把该文件加入运行器的复制清单。于是无论是否被变异，每次复制中那个测试都会失败，每个变异体都因同一个缺失文件而“死亡”。运行器自身的基线检查没有发现这个问题，因为它是在源文件夹上运行的，那里文件是存在的。这比浪费一个上午更糟。同一个 bug 早已让一次更早的“11/11 全杀”作废，而那次改动我已经发布，那个数字还躺在我的变更日志里作为证据。修复运行器后，那 11 个结果经受住了检验，对这 252 个变异体的完整重跑也真正地把它们全部杀死了。但在那三天里，那个数字什么也证明不了。而且这已经不是第一次了。更早的一次运行跨过了午夜，它的测试虚拟环境放在 /tmp 下。虚拟环境的配置文件在夜里被删了（我想是 macOS 的临时文件清理干的），pytest 再也启动不了，而一个无法启动的测试套件就是全部失败。所以午夜之后的一切都被判定为“已杀”。我现在会这样做：每次运行都有一个对照组：一个只改注释的变更，它必须存活。如果对照组死了，这次运行作废。对照组会经历运行器自身的复制步骤，在运行前后各跑一次。在源文件夹上做基线检查，只会掩盖复制过程中缺失的文件。“已杀”本身不构成证据。日志会记录每次击杀中失败的具体测试名。如果某个测试名出现在每一次击杀中，那不是测试套件强大，而是有一个测试坏了。当某个测试开始读取新文件时，要把该文件在同一改动中加入复制清单。长时间运行要经过一个包装器，它会在运行前后对源文件夹做指纹记录（名称、大小、哈希），如果任何内容发生变化，就把这次运行标记为 VOID。Claude 曾经在一次运行中途添加了一个测试，导致后面的变异体面对的测试和前面的不一样。如果你在跑评测或用 LLM 当评委，道理相同：每次运行都要有一个必须通过的用例和一个必须失败的用例，且都经过完全相同的流程。100% 应该让你起疑，而不是让你高兴。