防止 AI 修改共享夹具后悄悄削弱测试

AI 改完代码，测试全绿，也可能悄悄削弱了测试。dev.to 的这篇文章关注 pytest 的共享夹具：代理只改一处 conftest.py，就可能改变多个用例的验证前提。作者提出，用依赖映射圈出受影响的测试，再用声明式契约检查夹具是否仍满足约定。

目前能确认什么

夹具（fixture）负责给测试准备数据、连接或客户端。多个用例共用夹具时，初始化逻辑的变化会传递到这些用例。节选举了几种修改：把作用域从 function 改成 session、增加 None 兜底、删除夹具里的保护性断言。测试可能继续通过，但通过的原因已经变了。

作者给出的流程是：通过普通 pytest 插件，在收集阶段导出测试与夹具的对应关系；比较补丁前后的映射及夹具定义；用 YAML 声明非空、长度范围、必要属性等约束；运行契约测试和受影响的用例。

测试全绿，只能说明现有检查通过，不能证明验证条件没有被削弱。

方案也有明确缺口：正则无法完整归因插件或辅助模块中的夹具；部分变更需要人工或模型理解语义。示例遇到未实现的契约检查会标记为 skip，不会让构建失败。

我的判断

对接受 AI 补丁的团队，最有价值的是把 conftest.py 纳入重点审查：修业务代码时顺手修改共享准备逻辑，应当说明哪些测试受影响、哪些前提仍成立。

但当前节选还不足以支撑直接部署验收门禁。受影响用例的筛选脚本没有展开，契约示例中的 min_rows 也没有实现；如果 CI 允许这些检查跳过，门禁就可能留下空洞。契约本身也要人工审核，否则模型可能把已经放宽的行为写成新标准。

文章披露了 MonkeyCode 产品推广背景，其中的免费服务说法不能作为方案可用性的保证。技术流程可以独立审视，实际覆盖能力仍需完整实现来确认。