Vibe Coding 把测试当行为文档：从夹具、断言与失败路径读需求

陌生代码库里，README 往往解释产品想做什么，测试则更接近代码当前被要求做什么。但“测试就是文档”也容易被过度理解：测试可能陈旧、被跳过、只覆盖实现细节，或者和错误实现一起自洽。Vibe Coding 的正确做法不是盲从测试，而是把它当作一类可执行证据，与调用方、公开接口和任务验收交叉核对。

从测试入口而不是文件名开始

先确认测试如何被发现和运行：package script、runner 配置、文件 glob、项目引用、环境 setup、数据库或浏览器前置。一个名为 user.test.ts 的文件如果不在发现规则内，就不是当前门禁；带 .skip、条件环境变量或 quarantine 标签的测试也不能算作活跃行为证明。

记录测试命令、工作目录和基线结果。Node 的内置 test runner、pytest 等工具都有各自的发现、fixture 和生命周期语义，不能凭另一个框架的经验解释。先读仓库锁定版本随附或官方文档，再看本地配置覆盖。

一条测试要拆成五层读

不要只让 AI 总结 it("returns 403") 的名字。逐层提取：

1. 前置状态：fixture 创建了哪些身份、资源、时钟和功能开关。
2. 刺激动作：调用的是公共入口、内部函数还是 UI 交互。
3. 可观察结果：状态码、返回值、页面、数据库、事件或日志。
4. 负向结果：什么必须没有发生，例如没有写行、没有发消息。
5. 清理与隔离：状态是否在用例间重置，并发时是否共享资源。

fixture 是行为的一部分。pytest 文档专门解释 fixture 的依赖与作用域；在其他 runner 中，setup helper 也可能隐藏同样的重要状态。AI 若只复制测试主体，可能漏掉全局 mock、冻结时间或默认登录身份，从而误判真实契约。

Behavior claim: 非所有者不能修改草稿
Given: user B 登录，draft.owner=user A
When: PATCH public API, not service function
Then: 403; draft version unchanged; audit contains denial
Evidence: authz.integration.test.ts + route contract
Unknown: queue consumer 是否也能修改同一 draft

区分行为断言和实现断言

Testing Library 的指导原则强调测试应尽量贴近用户使用方式。这个原则也适用于服务端：优先把公开输入输出和持久副作用当契约，而不是锁定私有函数调用次数、DOM 内部层级或某个临时对象形状。实现断言并非一律错误，但它们更多是在约束当前结构，不应自动升级为产品需求。

让 AI 给每个断言标注 public-behavior、integration-contract、regression-detail 或 implementation-detail，并写出判断理由。准备重构时，前两类通常必须保持；后两类要结合 bug 历史和维护者意图决定。这样不会为了让旧 mock 继续通过而保留一个已不需要的内部层。

用正向、负向和边界三角验证

单个 happy path 很容易和实现共享盲点。围绕目标行为寻找一组证据：正常输入成功，明确禁止输入失败，边界输入保持约定。权限改动至少检查允许与拒绝；解析改动至少检查有效、无效和缺失；重试改动还要检查副作用没有重复。

AI 生成代码的属性测试可扩展组合边界，AI 测试生成实战能帮助提出候选用例。但 AI 新生成的测试不能为自己的实现自证：先证明测试在旧代码上按预期失败或捕捉已知变异，再让补丁使其通过。AI 生成补丁的变异测试进一步检验测试是否真的会拒绝错误实现。

处理测试与实现冲突

测试失败不一定代表实现错，也可能是 fixture 漂移、环境缺失、时间依赖或需求已经改变。冲突时不要立即改断言。先找公开类型、API 规范、变更历史、调用方和用户验收，形成三种裁决：测试正确、实现正确但测试过期、需求本身未决。第三种必须请求决策，不能让 AI 选择改动更少的一边。

若同一行为在单元和端到端测试中结论不同，检查它们是否走同一入口与配置。单元测试直接调用 service 可能绕过中间件；浏览器测试可能只看到了按钮隐藏，未验证服务端拒绝。这类差异正是测试作为行为文档最有价值的地方：它揭露行为在哪个边界才成立。

产出一张行为证据表

读完后，让 AI 输出“行为、入口、正向证据、负向证据、副作用、来源文件、活跃状态、未知项”，而不是泛泛总结测试覆盖率。拟议修改逐条映射到表中的行为；没有判定器的关键行为先补 characterization test，再动实现。编程 Agent 的改动验证门用于把这些证据纳入最终检查。

测试可以成为最接近运行事实的文档，但前提是确认它真的被执行、读完整夹具和断言、区分公共行为与内部结构，并允许证据冲突被显式呈现。这样 AI 不是“照着测试改到绿”，而是利用测试恢复需求、制造失败判据，再证明补丁改变了正确的行为。

延伸阅读

• AI 测试生成实战
• AI 生成代码的属性测试
• AI 生成补丁的变异测试
• 编程 Agent 的改动验证门