测试支撑与契约测试工具
一组接口测试在开发机连续通过，进入 CI 后却随机失败：有时数据库端口已监听但 migration 尚未完成，有时并行任务复用了同一个 Redis key prefix，有时 Pact 文件生成成功却从未验证 provider，还有一次 WireMock 录制把真实 Authorization 和客户地址写进了 artifact。团队拥有不少测试代码，缺少的却是稳定的依赖生命周期、数据隔离、契约发布与失败证据。
测试支撑工具不是为了让测试“更像生产”这一句口号，而是要把每个外部条件变成可声明、可启动、可等待、可隔离、可验证和可清理的对象。成功标准也不是一行绿色日志，而是能回答：依赖由谁创建、何时可用、测试连接的是哪个实例、数据属于哪个 worker、交互契约由谁验证、失败能否重放，以及 runner 退出后是否还残留容器、端口、文件、Broker 版本或敏感 artifact。
从失败信号选择工程入口
| 现场信号 | 工程入口 | 应得到的证据 |
|---|---|---|
| 测试依赖数据库、Redis、MQ 或对象存储，本机/CI 的地址、版本和清理方式不一致 | Testcontainers | 测试自动启动临时依赖，等待真实就绪，使用动态 endpoint，失败后资源可清理 |
| 消费者和 provider 独立发布，接口变更直到集成环境才暴露 | Pact | consumer expectation 形成版本契约，provider verification 和部署门禁能阻断破坏性变更 |
| 外部 HTTP 服务不稳定或昂贵，需要可控响应、错误、延迟与状态流 | WireMock 契约与 fixtures | 精确请求匹配、正反响应、scenario reset 和 fixture 漂移检查都可重复 |
| 单测在不同语言、worker、时区或 CI shard 中表现不同，fixture 清理经常遗漏 | 单测运行器与 fixtures | 生命周期、scope、随机种子、临时目录和并行隔离明确，本机与 CI 结果一致 |
四类工具可以组合，但不能互相冒充。Testcontainers 管理真实软件进程和网络边界，不保证业务契约正确；Pact 验证消费者与 provider 的交互兼容，不代替 provider 自身功能测试；WireMock 提供可控 HTTP 替身，不证明真实服务行为没有漂移；runner 和 fixtures 管理测试生命周期，不应偷偷连接共享环境来换取“真实感”。
一次测试怎样形成可复现证据
稳定测试链先确定隔离单元。一个测试方法、测试类、worker、测试套件或整条流水线都可能拥有不同 scope；scope 越大，启动成本越低，状态污染与并发冲突越难控制。依赖启动后不能只等待端口打开，应等待健康检查、协议握手、migration 完成或业务探针。连接信息必须从运行对象动态取得，不能把随机端口又写回固定配置。
fixture 只在依赖就绪后加载，并携带唯一 namespace、tenant、schema、topic、目录或 key prefix。断言同时覆盖正向结果与反向拒绝，失败时保留镜像摘要、容器日志、随机种子、时区、worker、契约版本和 request matching 证据。teardown 即使在断言失败、超时或进程中断时也要执行，并由外层清理器处理孤儿资源。
临时依赖不等于随便启动容器
Testcontainers 需要发现可用 runtime。开发机可能是 Docker Desktop，CI 可能挂载宿主 socket，也可能使用 DinD、remote daemon 或 rootless 环境；它们的网络、权限和清理能力不同。把 /var/run/docker.sock 挂进容器意味着获得宿主级高权限，不能因“只是测试”就忽略 runner 隔离。代理、私有 registry、CA、镜像限流和多架构 manifest 也会直接决定测试能否启动。
镜像版本应固定到可复现标签，关键链路可进一步记录 digest。固定容器端口只表示容器内部监听，宿主端口优先动态映射；测试从 container object 获取 host/port。多个容器通过独立 network alias 通信，应用在宿主运行与应用也在容器运行时，连接地址不是同一个概念。
reuse 可以缩短本地反馈，但会保留 schema、queue、extension 和缓存状态，不能默认用于 CI 或隔离要求高的测试。Ryuk 等清理机制也不是绝对保险：socket 不可达、权限不足或 runner 被强制终止时仍可能残留资源，团队需要 TTL 标签、定时巡检和按流水线关联 ID 清理的第二道防线。
契约必须经过 provider 验证
consumer test 只证明消费者对 Mock 的期待，不证明 provider 真的满足期待。Pact 文件需要绑定 consumer 版本和 branch/tag，发布到 Broker 后由对应 provider 版本执行 verification。验证结果再参与 can-i-deploy 或矩阵判断，才能回答某个 consumer/provider 组合是否已经被证明兼容。
如果只在 CI 上传 pact 文件，仪表盘会越来越热闹，部署风险却没有下降。pending/WIP 可以让新契约进入验证而不立刻阻断已有 provider，但它们不是永久忽略失败的开关。环境记录、部署版本和回滚状态也要准确，否则 Broker 根据错误事实给出的绿色门禁没有意义。
契约内容本身可能包含 header、标识符、路径和业务样例。示例使用合成值，token、Cookie、PII 和内部 URL 在生成前就应被替换；Broker 凭据使用短期或最小权限身份，日志不回显 token。契约保留策略还要兼顾回溯、成本和消费者退出，不能无限堆积所有分支产物。
Mock 与 fixtures 需要防漂移
WireMock 的价值在精确控制请求与响应。宽松到只匹配 URL 的 stub 会让错误 method、header、query、body 也得到成功响应；过度匹配随机 ID 和时间戳又会让测试脆弱。稳定策略是区分协议约束、业务关键字段和非决定性字段，并为未匹配请求、错误状态、超时、连接重置和状态迁移提供明确证据。
recording 可以快速建立初始 mapping，却也最容易复制真实敏感数据、偶发响应和无关 header。录制结果必须经过脱敏、最小化、命名、评审和版本化，不能直接作为长期真相。定期用真实 provider schema、契约或受控集成测试检查 Mock 漂移；一旦 provider 行为变化，fixture 与测试要在同一变更中更新。
scenario、request journal 和 in-memory state 会跨请求保留。每个测试或 worker 使用独立 server、独立 scenario namespace，或者在明确边界 reset；并行测试共享一个全局 WireMock 端口和状态，是典型的随机失败来源。
Runner 一致性来自显式环境
JUnit、pytest、Vitest 对测试发现、fixture scope、hook 顺序、并发、超时和失败退出码有不同默认值。仓库应固定运行器与插件版本，把命令、配置、时区、locale、编码、随机种子、worker 数和 shard 规则写进统一入口。本机 IDE 与 CI 最终调用同一任务，而不是各自维护一套隐藏参数。
时间、随机、临时目录、环境变量和全局进程状态都属于 fixture。测试使用可注入时钟、显式 seed 和 runner 提供的临时目录；清理代码放在 finally、fixture finalizer 或框架 teardown 中。并行执行时，每个 worker 获得唯一数据库 schema、端口、目录和消息 namespace，禁止依赖执行顺序。
retry 只能作为诊断手段，并记录首次失败、重试次数和 flaky owner；把重试后的绿色当作普通通过，会让不稳定性永久留在主干。coverage 说明哪些代码被执行，不证明断言质量、异常路径或契约兼容，不能代替行为门禁。
团队运行底线
测试默认不连接共享数据库、MQ、第三方账号或生产服务；例外需要独立环境、身份、数据与 owner。每个依赖固定版本并记录运行入口、就绪条件、动态 endpoint、资源 owner 和清理证据。Docker socket、remote daemon、registry、代理和 CA 按高权限基础设施治理，CI job 使用最小权限和隔离 runner。
Pact 必须完成 publish、provider verification 和部署矩阵闭环，不能以“契约文件已生成”作为完成标准。WireMock mapping 和 fixture 使用合成或脱敏数据，精确匹配关键协议，并通过真实 schema/契约持续检查漂移。runner、插件、时区、locale、编码、seed、worker 和 shard 参数在本机与 CI 中显式一致。
每个并行单元拥有独立目录、schema、topic、key prefix 和 scenario；失败也执行 teardown，并巡检孤儿资源。日志、契约、录制响应、报告、截图与 artifact 默认按敏感测试资产处理，设置访问权限和保留周期。flaky test、慢测试、镜像拉取、容器启动和 Broker 门禁都有指标、预算和 owner，不能靠无限 retry 掩盖。
当一条失败测试能带着版本、依赖、数据、随机种子、交互、契约和清理证据在另一台机器上复现，并且一条绿色流水线同时证明没有共享状态和残留资源，测试工具才真正成为交付基础设施，而不是开发机上的偶然便利。