1. README 计数去掉(不留守卫)
去掉「119 tests」与「10 checkpoints / 10/10 checkpoints passed」。
理由按裁定:一个没有守卫、被手改过五次的数字是负资产,
它给人的确定感是假的;加守卫要翻倍套件时间,不值。
守卫反过来断言「README 不得出现计数」:
/\b\d+\s+tests\b/i
/\b\d+\s+checkpoints\b/i
/\b\d+\s*\/\s*\d+\s+checkpoints passed/i
三种写法实测都能抓住(120 tests / 12 checkpoints / 12/12 passed)。
顺带处理一处同类:原文「(6 tests)」是手抄的测试数,删;
「12 blocks × 15 queries = 45 cases」是 fixture 自身内容量,也删并改为
指向 fixture 文件 —— 由文件决定的东西不该在文档里再写一份。
(README 现在的口径:表格说「验什么」,`npm test` / `npm run check` 说「多少」。)
2. docs/dev-notes-mutation-criteria.md(新)
把三轮踩出来的方法论落成仓库文档,README 的 Verify 段加指针。
三类失效模式,每条都给「形态 / 实测证据 / 正确形态 / 自查问句」:
① 自测型假变异(犯四次:W11† / W11d†a / W11d†b / W12†)
变异在 test/ 里自己拼替身,一行 lib/ 没碰 ⇒ 真回退下保持绿
实测:M-a / M-b 下 W11d†a / W11d†b 均绿,只有 W11d 红
② 清单写死(W11f)
手写 MODES 漏掉新 case;future_mode_a/b 测的是「掉进 default 的」,
永远测不到「有人新写了一个 case」
实测:植入 brand_new_mode(零命中时撒谎)→ 写死版全绿,扫描版红
并记下边界:自动推导不能替代「提取本身也要被守卫」,
所以还需要 declared.length >= 4 + W11f-a(guards the guard)
③ 变异共享状态并发撞车(我自己引入的)
就地改写 lib/*.js,而 node --test 并行跑文件 ⇒ 别的文件读到中间态
实测:约 1/30 偶发失败,症状像 flaky 断言;A1b / G2b / G5 这类
读源码的判据会读到被改坏的中间态
修法:在 lib/ 副本上变异(复制 lib + package.json + 软链 node_modules),
finally 清理,锚点失配显式失败
文末给通用自查清单 9 条 + 一句话记住三条。
验证
- npm test 119/119、npm run check 10/10
- 连跑 6 次全量 0 失败
- 无 .orig / .rej / /tmp/mut-* 残留
- 未 amend / 未 force push,199553f 之后是新提交
8.4 KiB
变异判据的三类失效模式
来源:phase B(H 组 W1–W12)三轮返工中实际踩到、并由评审独立复现的坑。 三条都不是本任务特有的,任何写变异判据的人都会再踩。
共同点:它们都让判据绿着,而判据守的东西已经坏了。 这类问题比被测代码坏了更难发现, 因为失败的信号本身就是「一切正常」。
0. 一句话总纲
变异体必须让
lib/下的代码变坏。 一旦变异动的是test/、或者断言的是测试里自己拼的局部函数,它就不是变异,是自测。
把这一条当硬规则执行,下面三条里至少两条会被自动拦住。
1. 自测型假变异(犯得最多:四次)
形态
"变异"测试在 test/ 里自己拼一个替身,再断言替身的行为:
// ✗ 这不是变异
test('W11d†a: restoring the short-circuit breaks it', () => {
const withShortCircuit = (hits) => (hits.length === 0 ? '' : renderRecall(hits)) // 自己拼的
assert.equal(withShortCircuit(empty), '', 'the short-circuit does silence it')
})
这段一行 lib/ 代码都没碰。它永远不会随实现回滚而变红,却按「已覆盖一条变异」计数。
实测证据
变异(真改 lib/) |
期望 | 实测 |
|---|---|---|
M-a 只回退 renderRecall 短路 |
W11d†a 红 |
W11d†a 绿,只有 W11d 红 |
M-b 只加回 contextForStep 短路 |
W11d†b 红 |
W11d†b 绿,只有 W11d 红 |
正确形态
真改源码 → 重新 import → 断言行为翻转 → 还原。
await withMutatedCopy('recall.js', [
[' if (lines.length === 0 && notice === \'\') return \'\'',
' if (lines.length === 0) return \'\' // MUTATED'],
], async (mod) => {
const hits = []; hits.degraded = 'embed_error'
assert.equal(mod.renderRecall(hits, 'x'), '', 'mutation makes it render nothing')
})
三条要求:
- 改的是
lib/,不是test/。 - 锚点找不到时显式失败(
assert.ok(text.includes(from))),否则源码一改名,变异静默失效。 - 改在副本上,见 §3。
自查问句
把
lib/完全回滚到上一个版本,这条测试会红吗? 不会 → 它是自测,删掉,别留在计数里。
2. 清单写死(判据的输入与代码脱节)
形态
判据遍历一份手写的清单,而清单本该覆盖的东西由代码决定:
const MODES = ['no_embedder', 'embed_error', 'aborted', 'vector_ready_unused',
'future_mode_a', 'future_mode_b'] // ✗ 手写
future_mode_a/b 这类名字有误导性:它们测的是「掉进 default: 的未知模式」,
永远测不到「有人新写了一个 case」。而正常演进偏偏就是新写 case ——
那种时候 default: 和手写清单两头都管不到。
实测证据
在 lib/recall.js 里植入一个会撒谎的新分支:
case 'brand_new_mode':
return '[Memory] New mode degraded; matches below may be incomplete.' // 零命中时是谎话
| 版本 | W11f |
W11f† |
W11f†b |
|---|---|---|---|
写死 MODES |
绿 | 绿 | 绿 |
| 源码扫描 | 红 | 绿 | 绿 |
写死版全绿,因为 brand_new_mode 不在数组里。
正确形态
清单从被测代码推导,而不是手抄:
const src = readFileSync(new URL('../lib/recall.js', import.meta.url), 'utf8')
const body = src.slice(src.indexOf('export function degradationNotice('))
const declared = [...body.slice(0, body.indexOf('\n}\n')).matchAll(/case '([^']+)':/g)]
.map((m) => m[1])
★ 但「自动推导」不能替代「提取本身也要被守卫」
推导源必须是判据真正要管的那件事。case 'literal' 恰好就是「有哪些模式」的唯一事实源;
一旦 degradationNotice 改成表驱动(模式放进映射表),扫描就会静默扫到空数组而照样绿。
所以必须配两道:
| 守卫 | 作用 | 实测 |
|---|---|---|
declared.length >= 4 + 必需 mode 存在性 |
提取失效时响亮失败 | 把 case 'x' 全改成常量引用(语法合法、仍可导入)→ expected at least 4 case literals, found 0 |
W11f-a(guards the guard) |
用变异塞一个新 case,断言扫描看得见它 |
塞 mode_added_by_the_future_test → 能取到 |
W11f-a 不是冗余:「扫描器坏掉」是这套判据唯一能静默失效的方式。
同一族的另一种:README 里的数字
README 曾写着「N tests / M checkpoints」,被手改过五次,两次是在 commit message 里漂的。 加守卫来盯着这个数字,成本高于数字本身的价值。
结论:删掉,不守着。 留下的守卫反过来断言「README 不得出现计数」:
[/\b\d+\s+tests\b/i, 'a test count'],
[/\b\d+\s+checkpoints\b/i, 'a checkpoint count'],
[/\b\d+\s*\/\s*\d+\s+checkpoints passed/i, 'a pasted pass-count'],
三种写法实测都能抓住。一个没有人验证的数字,给人一种精确的假象。
注意区分两类数字:
- 手抄的运行计数(「119 tests」)——会漂,删。
- 制品自身的内容量(「fixture 里有 45 个 case」)——由文件决定,但同样没有守卫, 所以也不要写进文档,改为指向文件本身。
3. 变异共享状态与并发撞车(ESM / 测试并行)
形态
node --test 默认并行跑测试文件(每个文件一个进程)。变异若直接改写共享的 lib/*.js:
// ✗ 与其它测试文件并发时不安全
writeFileSync(src, mutated) // 别的文件此刻可能正在 import 它
const mod = await import(`${url}?mut=1`)
writeFileSync(src, original)
别的测试文件在变异窗口内 import,就读到中间态。
实测证据
- 症状:约 1/30 偶发失败,看起来像「断言 flaky」而不是 harness 竞态。
- 具体表现:
W11d†抓到的是未变异的模块,于是断言失败但原因完全错位。 - 更隐蔽的一层:
A1b(逐字节比对recallBlocks源码)、G2b/G5(扫lib/全目录) 这三条专门读源码的判据,在就地变异下会读到被改坏的中间态。
正确形态
在副本上变异:
const dir = mkdtempSync(join(tmpdir(), 'mut-'))
cpSync(libDir, join(dir, 'lib'), { recursive: true })
cpSync(join(pkgRoot, 'package.json'), join(dir, 'package.json'))
cpSync(join(pkgRoot, 'node_modules'), join(dir, 'node_modules'), { recursive: true, dereference: false })
// 改 dir/lib/<file>,import dir/lib/<file>
// finally: rmSync(dir, ...)
要点:
- 复制
lib/整体(保留目录形状,相对 import 才能在副本内解析到被变异的兄弟模块)。 - 复制
package.json("type": "module")。 node_modules软链/保留符号链接(dereference: false),否则 peer 依赖解析不到。finally里rmSync,否则/tmp堆副本。- 锚点匹配不到时显式失败,别静默跳过。
验证方式
- 连续 30 次全量跑,0 失败(改前约 1/30 偶发)。
- 跑完
ls -d /tmp/mut-?????? | wc -l应为 0(无残留)。 - 并行压力:
a + g-static + h三文件同跑 5 轮 0 红。
附带的 ESM 坑:
package.json里"type": "module"时,测试文件不能用require(), 一律await import('node:fs')。用require会报Cannot determine intended module format(顶层 await 与 require 并存)。
通用自查清单
写/改一条变异判据前,逐条过:
- 变异体只改
lib/(改test/的是自测) - 把
lib/回滚到上一版,这条测试会红 - 锚点找不到时显式失败,不是静默 pass
- 清单/枚举从代码推导,不手抄
- 推导本身有长度下限 + 必需项断言;另有一条 guards-the-guard
- 变异在副本上做,
finally清理,不碰共享树 - 跑完确认无残留(
.orig/.rej//tmp/mut-*) - 连跑 ≥5 次(间歇性问题 3 次绿证明不了什么)
- 文档里没有手抄的运行计数
一句话记住三条
| 坑 | 一句话 |
|---|---|
| 自测型假变异 | 变异不碰 lib/,它就永远不会红。 |
| 清单写死 | 判据的输入和代码脱节时,绿的是记忆不是事实。 |
| 并发撞车 | 变异共享状态不能与代码并发跑 —— 改副本。 |