Vibe Coding 集成测试边界：在真实协作与可控替身之间划线

集成测试最容易走向两个极端。一端把 repository、HTTP client、队列和时钟全部 mock，测试只证明这些 mock 会返回自己配置的值；另一端每个 PR 都连接共享数据库、真实支付沙箱和远程消息系统，结果受网络、脏数据和配额影响，失败无法重放。AI 能迅速生成任一极端的大量代码，却不会自动知道团队真正拥有哪一段契约。

边界设计的目标，是让一个测试内部的关键协作尽量真实，同时把不可控世界隔离在明确端口。先由编程 Agent 的仓库地图确认进程、数据所有者和调用方向，再决定在哪一层替换依赖；不要根据“mock 写起来方便”划线。

用四个问题识别集成边界

第一，调用是否跨进程或跨发布单元。第二，协议是否由另一个团队或供应商拥有。第三，数据是否由当前服务负责持久化。第四，调用是否产生不可逆副作用。答案决定测试需要证明什么，而不是直接决定一律 mock 或一律真实。

服务内部的路由、业务规则、序列化与 repository 通常应一起运行，配一个隔离数据库，才能发现事务、映射和约束错误。发邮件、扣款和第三方搜索属于外部副作用，PR 测试使用可验证请求的本地替身，不真执行动作。对自己拥有的下游服务，可增加跨版本契约和独立的端到端环境；对供应商 API，则以官方 schema、录制的脱敏样本和少量受控探针验证适配层。

一张边界表至少包含：消费者、提供者、传输、契约制品、测试内真实部分、替身部分、失败注入和真实验证频率。比如：

“真实 schema”意味着测试迁移与候选代码使用同一版本；内存对象不能替代数据库唯一约束和事务隔离。反过来，PR 测试不应持有生产凭据，第三方沙箱也不能被当成永远稳定的单元测试 fixture。

契约不只是一份 JSON Schema

OpenAPI 可以描述 HTTP 路径、参数、响应和安全要求，AsyncAPI 可描述消息接口；它们都不能自动表达所有业务语义。集成测试还要检查默认值、错误码、幂等、分页、重试提示、事件顺序与兼容窗口。更完整的跨版本门禁可参考Agent API 契约兼容门。

消费者驱动契约由真实消费者声明自己依赖的交互，再由提供者版本验证。Pact 的消息测试文档区分消息内容生成与消费者处理，适合提醒团队同时验证生产和消费两侧。契约制品需要绑定消费者提交、提供者版本与哈希；让 AI 在同一补丁中同时改 provider 输出和 consumer 期望，很可能只是把破坏同步隐藏。

替身必须严格到会拒绝未知字段、错误类型和错误调用顺序。一个总是返回 200 { ok: true } 的 fake 无法发现 Authorization 头缺失、金额单位错误或超时取消失效。可以从规范生成基础验证，再人工补业务不变量。断言为何可信，应按Vibe Coding 测试预言审查追溯来源。

把失败语义当作一等契约

正常响应只是接口的一小部分。跨边界测试至少注入连接拒绝、响应超时、半包或非法 JSON、限流、可重试服务器错误、永久客户端错误、重复消息和调用方取消。每种失败都要给出终态：是否重试、重试上限、是否写入幂等记录、用户看见什么、是否留下待恢复任务。

不要用“抛了任意异常”作为统一答案。支付超时可能处于结果未知状态，不能立即当失败重扣；消息确认丢失可能导致重复投递，消费者必须幂等；数据库提交失败必须证明没有部分副作用。跨服务定位可以关联分布式追踪，但 trace 只能展示发生了什么，测试仍需明确什么行为被允许。

组合三层证据

第一层是快速、确定的组件集成测试：当前服务真实运行，外部边界使用严格替身。第二层是契约验证：候选消费者与受支持提供者版本交叉检查。第三层是数量有限的真实探针或端到端测试，用来发现替身与真实系统漂移。三层结果分别报告，不能用“集成测试通过”混成一个绿色标记。

真实探针失败时先判断产品回归、外部波动还是环境问题，并保留请求 ID、版本和脱敏响应。替身与真实服务出现差异，先修契约和 fixture，再让 PR 门恢复；不能因为远端偶发失败就永久关闭真实验证。编程 Agent 的改动验证门可绑定各层证据与 HEAD，避免测试后继续改代码。

最终审查问六件事：边界为何选在这里；测试内哪些组件是真的；替身依据哪个版本；失败和恢复是否被覆盖；数据是否隔离并可清理；是否有机制发现真实服务漂移。回答清楚后，AI 才适合批量生成测试实现。边界不是“mock 数量”的风格选择，而是对这组测试能够证明到哪里、不能证明到哪里的公开声明。

延伸阅读

• 编程 Agent 的仓库地图
• Agent API 契约兼容门
• Vibe Coding 测试预言审查
• 分布式追踪
• 编程 Agent 的改动验证门