AI补丁偷偷改了测试夹具？先给setup层做指纹

AI 编码代理提交的补丁，常常能让原本报错的测试套件变绿——但代价可能是悄悄改写了测试的 setup 层。conftest.py、工厂函数、种子数据、golden 文件，这些文件不包含断言，却决定了测试运行在怎样的「世界」里。如果审查只盯着 src/ 和 tests/ 的 diff，这一层就被漏掉了。

本文提供一套可以直接接入 CI 的小脚本：对 fixture 文件做内容指纹、记录测试与 fixture 的映射、对 fixture 本身写属性断言，以及一个带过期时间的 flake 冻结台账。不是框架，是几段能跑的检查。

失败模式：套件是绿的，世界变了

AI 补丁反复出现三种形态。工厂函数开始返回 email 相同的对象，唯一性检查变成不可达代码。conftest.py 里的 fixture 不再回滚数据库会话，测试 N+1 能看到测试 N 留下的行。golden JSON 文件被重新生成以匹配新输出，断言实际上变成了补丁与自己的比较。

这三种情况都能让套件「诚实地」通过，但没有一个是人肉审查时会放行的改动。解决办法是把 setup 层变成显式、可审查的输入。

第一步：给 setup 层做内容指纹

对每一个可能改变测试状态而非测试断言的文件计算 SHA-256 摘要。脚本遍历 conftest.py、tests/fixtures/**/*.py、tests/factories/**/*.py、tests/data/**/*，输出排序后的路径到哈希映射。

**SHA-256 与内容指纹**：SHA-256 是 SHA-2 家族中的一种密码学哈希函数，对任意长度输入产生固定的 256 位（64 个十六进制字符）摘要，具有抗碰撞性和雪崩效应——输入哪怕只改一个字节，输出也会面目全非。用它做「内容指纹」意味着比较的是文件字节的完整身份，而非修改时间或文件大小；后者在 git checkout、CI 缓存还原或编辑器自动格式化时都可能失真。把基线哈希提交进仓库，相当于给 setup 层拍了一张快照：补丁只要触碰过其中任何文件，指纹比较必然失配。需要留意的是，哈希只证明「变了」，不证明「变坏了」，所以它适合作为触发人工审查的红灯，而不是自动裁决对错的裁判。
# audit/setup_fingerprint.py
import hashlib, json, pathlib, sys

ROOT = pathlib.Path(__file__).resolve().parent.parent
GLOBS = ("conftest.py", "**/conftest.py", "tests/fixtures/**/*.py",
         "tests/factories/**/*.py", "tests/data/**/*")

def digest() -> dict[str, str]:
    out = {}
    for pattern in GLOBS:
        for path in ROOT.glob(pattern):
            if not path.is_file() or "__pycache__" in path.parts:
                continue
            rel = path.relative_to(ROOT).as_posix()
            out[rel] = hashlib.sha256(path.read_bytes()).hexdigest()
    return dict(sorted(out.items()))

在父树上运行一次 --write 生成 audit/setup_baseline.json 并提交，之后补丁运行时进入比较模式。退出码非零，就意味着审查者必须看一眼本来会被略过的 setup 文件。

第二步：记录哪个测试用了哪个 fixture

一个工厂函数变了，只有被某个测试消费过才重要。用 pytest 插件在正常收集阶段记录映射：pytest_collection_modifyitems 里遍历每个 item 的 fixturenames，pytest_sessionfinish 时落盘为 audit/fixture_usage.json。在根 conftest.py 里用 pytest_plugins 启用，保证 CI 和本地行为一致。

这个映射是启发式的：它记录 fixture 的名字而非定义位置，需要配合在 setup 目录下 grep def <name>( 来把 fixture 归因到文件。它回答不了调用图，但足以回答「还有人在用这个吗」——并且对自身局限是诚实的。

pytest 的 fixture 解析与 collection 钩子：pytest 在执行测试前先做 collection，把每个测试函数包装成 Item，其 fixturenames 属性列出该测试（含间接依赖）请求的全部 fixture 名。pytest_collection_modifyitems 是 collection 结束、执行开始之间的钩子，此时可以遍历全部 item 建立「测试 → fixture 名」映射；pytest_sessionfinish 则在会话收尾时提供落盘时机。由于 fixture 可以定义在任意 conftest 层级、也可通过 @pytest.fixture 在模块内定义，钩子拿到的是名字而非定义位置——这正是文中说映射是启发式的原因。若想更精确，可结合 item._fixtureinfo.name2fixturedefs 取得 FixtureDef 及其定义模块，但代价是依赖 pytest 内部结构，升级时容易断裂。

第三步：断言 fixture 的属性，而不只是输出

fixture 的 bug 本质是不变量 bug。写几条属性断言，让 setup 层漂移时大声失败：

def test_factory_ids_are_unique():
    ids = {make_user().id for _ in range(500)}
    assert len(ids) == 500, f"factory collided: {500 - len(ids)} duplicates"

def test_factory_does_not_leak_defaults():
    a, b = make_user(), make_user()
    assert a.email != b.email, "email default is a constant"
    assert a.created_at <= b.created_at, "created_at is not monotonic"

def test_db_fixture_isolates_writes(db_session):
    db_session.add(make_user(email="isolation@example.com"))
    db_session.flush()
    assert db_session.query(type(make_user())).count() == 1

三条属性、一分钟运行时，正好抓住那类把断言变成同义反复的补丁。把这个文件放在补丁作者不太可能碰的位置，一旦变更就要求人工审查。

基于属性的测试（property-based testing）：与给定输入断言输出的示例测试不同，属性测试断言的是对任意输入都应成立的不变量，例如「任意两次调用工厂得到的 ID 互不相同」。这类断言不关心具体值，只关心关系，因而对实现细节的漂移极其敏感——工厂把 uuid4() 换成固定字符串、把自增时间戳换成常量，输出示例测试可能照常通过，属性断言则立即失败。文中三条断言分别对应唯一性、默认值独立性和事务隔离三类典型不变量。若想进一步自动化，可引入 Hypothesis 之类的库自动生成输入并做收缩（shrinking），但对手写三条断言而言，直接 range(500) 循环已足够暴露碰撞，且运行时间可控、失败信息直观。

第四步：用带过期时间的台账冻结 flake

隔离某个 flaky 测试是合理的；永久隔离、或者隔离补丁自己新引入的测试，则不合理。把冻结做成数据而不是注释：audit/flake_ledger.json 每条记录包含 test、frozen_at、expires、reason、owner。

三条规则让台账有用。expires 必填且最多 30 天，过期条目直接让 CI 失败。依赖冻结的补丁不得同时修改被冻结的测试——先解冻再改。新加入的测试永远不能出现在台账里，你不能冻结自己刚造出来的证据。

flake 与隔离冻结：flake（flaky test）指同一代码、同一环境下结果不确定的测试，常见成因是执行顺序依赖、共享可变状态、时间/时区敏感、并发竞态或外部服务抖动。工程上短期做法是 skip/xfail 将其隔离，让主干 CI 保持可信；但隔离一旦没有期限，就会沉淀为「永久豁免」，被冻结的测试往往再也不会被修复，覆盖缺口悄然扩大。带过期时间的台账把隔离变成一条有 owner、有理由、有到期日的显式债务记录，到期即让 CI 失败，逼迫团队要么修复要么重新评估。它与 xfail(strict=True) 的区别在于：后者只表达「预期失败」，不管理期限与责任人，也不阻止同一补丁顺手改写被冻结的测试。

第五步：一个门禁强制以上四项

audit/gate.py 作为 CI 第一步，在测试之前运行，耗时不到一秒。它检查：setup 层被改动却没有 audit/fixture_changes.md 变更说明、台账条目过期、补丁编辑了被冻结的测试、新提交的测试已经处于冻结状态。任意一条命中，输出 FAIL 并以非零退出。它抓住的正是人工审查可靠遗漏的两件事：静默的 setup 改动和自授的隔离。

MonkeyCode 的适用边界

提出属性候选是最枯燥的环节：读一个工厂函数，然后发明不变量。原文作者用 MonkeyCode 的免费模型额度做这个提议循环——把 fixture 文件丢进去，要五个候选属性，保留可证伪的，扔掉其余的。上面的门禁本身保持确定性，合并时没有任何模型参与推理。它的免费服务器选项是另一半用途：对疑似 flake 做一周重复运行的采样，需要的是一台既不是你的笔记本、也不是计费 CI runner 的机器。

披露：原文是作为 MonkeyCode 产品推广的一部分撰写的。

红色运行出现时的决策表

观察到的现象	最可能的原因	应采取的动作
setup 指纹变了，但没有 fixture 变更日志	补丁改写了 fixture 或种子数据	要求 audit/fixture_changes.md，先审 fixture diff
指纹干净，单个测试在多次运行间翻转	真正的 flake，或顺序依赖	采样 20 次；若翻转则带期限冻结，绝不内联
指纹干净，测试现在因错误原因通过	断言被弱化或属性被删除	diff tests/test_setup_properties.py，恢复它
工厂改动后属性测试失败	setup 变更破坏了不变量	修工厂，不要放宽属性
同一补丁中编辑了被冻结的测试	把隔离当捷径	拒绝；解冻、修复、必要时重新冻结

局限，以及谁应该跳过

这道门禁管的是状态，不是正确性。它不会告诉你补丁是否修复了 bug，只告诉你测试世界是否仍然可比。fixture 使用映射基于名字，会过度归因共享基类中定义的 fixture。属性文件需要人持续维护其意义——三条吵闹的属性比没有更糟。

如果你的套件小到审查者会读每一个 fixture diff，如果没有 CI 可以挂脚本，或者 flake 来自无法重放的第三方网络调用（那里诚实的修法是录制传输层而不是更长的冻结），那就跳过。如果团队把 audit/flake_ledger.json 当成永久停放问题的地方，删掉台账——你建的是纪念碑，不是门禁。

从第一步开始。一个基线文件，一秒 CI 时间，下一个悄悄重写 conftest.py 的 AI 补丁就会以红线出现，而不是绿油油的套件。