Vibe Coding 的 AI 生成测试审查：把测试代码当生产代码验收
AI 能快速补齐测试文件，也能复制实现、制造脆弱 mock 和用宽断言换绿色。本文给出从需求映射、失败证明到变异校准的审查顺序，确保新增测试真的会拦住错误。
本文要点
- 主题聚焦：Vibe Coding、AI Agent、TypeScript、DevOps
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
AI 提交的测试往往比实现更容易得到快速批准：文件名像测试，CI 也是绿色，覆盖率还上升。可测试代码同样会有缺陷，而且一旦错误测试进入主干，它会长期给错误实现背书。常见问题包括复制生产算法计算期望、只验证 mock 调用、不等待异步断言、共享状态泄漏、快照未审阅，以及为了稳定而增加重试或跳过。
审查顺序应从“它要保护什么”开始，而不是从代码风格开始。先读需求和生产 diff，再看测试设计，最后才检查语法与抽象。通用评审方法见AI Code Review 实践；这里把关注点收窄到测试是否具备真实的失败能力。
建立需求到用例的映射
要求作者提供一张简短映射：风险或验收条件、用例 ID、输入、观察结果、预言依据。happy path 只能证明功能在一个条件下可用；边界、拒绝、重试、幂等、权限和清理失败必须按改动风险选择。可用Vibe Coding 测试矩阵整理状态组合。
若 AI 从实现分支直接生成测试，reviewer 要回到外部行为。新增 if (role === "admin") 不代表只需测 admin；至少要问普通用户、资源 owner、未知角色和角色变化后缓存如何处理。删除代码也需要测试：旧行为是否应消失，旧调用方会看到什么。只有覆盖率新增而没有需求映射的案例，应视为待解释，不视为完成。
先证明测试会红
新测试在修复后的 HEAD 通过，只说明实现和测试相容。最有力的快速检查是让它在修复前版本或临时撤销关键改动后失败，并确认失败消息指向目标行为。回归测试若在 BASE_SHA 也通过，就没有证明它捕捉了本次缺陷；新功能测试可以没有旧实现，但应在移除关键分支、反转条件或破坏副作用后失败。
系统化校准可使用AI 生成补丁的变异测试。不要只看总 mutation score，先检查本次新增的鉴权、金额和状态条件是否有幸存变异。Stryker 文档区分 killed、survived、no coverage、timeout 等状态；timeout 不是 killed，编译失败也不能自动证明断言有效。
Jest 覆盖率能显示语句、分支和函数是否执行，却不证明输出被正确检查。覆盖率上升是导航信号，不是质量结论。一个没有断言的测试也可能覆盖整条路径。因此审查报告同时展示关键失败校准和覆盖变化，且前者优先。
专查五类生成式缺陷
第一类是循环预言：测试复制实现或调用另一个共享 helper 计算 expected。依据应来自需求、独立模型或不变量，详见Vibe Coding 测试预言审查。第二类是过宽断言，例如只看 truthy、任意异常或对象包含一个无关字段。第三类是过度 mock：所有内部协作者都是假对象，真实代码几乎没运行。
第四类是异步假绿。Promise 没有 await 或 return，回调断言可能在测试结束后才执行；预期抛错却没有检查 assertion count；fake timer 未恢复会污染后续用例。第五类是状态污染：模块级单例、数据库记录、环境变量、时区或 mock history 没有在每例重置。单独运行通过、换顺序失败就是明显信号。
还要搜索门禁削弱：新增 .skip、.only、全局 retries、超时放大、覆盖率排除和 snapshot 自动更新。它们不一定永远错误，但必须在 diff 中有具体原因、到期条件和替代保护。GitHub Actions workflow 里的 continue-on-error、路径过滤和条件表达式同样可能让测试根本没有阻断合并，不能只审测试文件。
审查 fixture、mock 与失败消息
fixture 应最小但真实。大型工厂默认填满所有字段，会让用例名声称“缺少昵称”，实际仍从默认值获得昵称。每个关键边界在执行前最好有显式前置断言或清晰 builder。时间和随机要注入或固定，外部服务在清楚边界处替换；内部业务对象尽量使用真实实现。具体边界策略见Vibe Coding 集成测试边界。
mock 断言要连接业务结果。toHaveBeenCalledTimes(1) 只有在“一次副作用”本身是契约时才有价值，还应检查参数和最终状态。不要断言 ORM 或框架内部调用顺序，除非顺序影响事务语义。错误消息要能识别案例、输入与差异；快照失败若产生数百行噪声，拆成关键字段断言。
用独立执行完成验收
reviewer 从干净工作树安装锁定依赖，运行新测试、相关领域套件和仓库规定的静态检查。记录 HEAD、命令、测试选择理由、结果和环境。若只跑受影响测试，选择逻辑可参考编程 Agent 的测试影响分析，未知影响应升级到更大范围。
失败时不允许 AI 自动把期望改成实际值。先分类为实现错误、测试错误、需求歧义、fixture 错误或环境问题；每轮只改变一个假设并重跑原失败。完成门包含：需求映射无缺口；关键测试在坏实现上失败；断言有独立依据；mock 位于明确边界；无未解释的跳过与放宽；相关测试在同一 HEAD 通过。
把测试当生产代码，不是要求它同样复杂，而是承认它决定了哪些错误能进入生产。AI 可以承担铺设参数表、fixture 和重复断言的劳动，reviewer 必须守住风险选择与正确性依据。绿色只是执行结果，能够可靠地在错误出现时变红，才是测试被接受的理由。
延伸阅读
Related