Bind Mount 如何在自动化测试中快速注入测试桩数据

Bind Mount 通过挂载宿主机静态桩文件实现数据传递，适用于 JSON 配置、Mock 响应、数据库快照等预置场景；需版本控制、只读挂载，并配合脚本切换桩集，动态模拟则需结合 HTTP stub 服务。

Bind Mount 本身不“注入”测试桩，而是把宿主机上已准备好的桩数据文件或目录，直接挂载进测试容器——相当于用文件系统做数据传递。它适合那些不需要运行时动态生成、结构稳定、可预先写死的测试桩（如 JSON 配置、Mock API 响应体、固定数据库 dump 文件等）。

提前准备好桩数据文件

在项目根目录或 tests/fixtures/ 下创建真实可用的桩内容：

1. tests/fixtures/mock_api_responses/user_404.json → 内容：{"error": "not found", "code": 404}
2. tests/fixtures/config/test.env → 模拟不同环境变量
3. tests/fixtures/db/dump.sql → 预置干净的测试数据库快照

这些文件是静态的、版本可控的，和代码一起提交，确保所有开发者与 CI 环境使用同一套桩数据。

用 -v 挂载到容器指定路径

启动测试容器时，把本地桩目录映射过去，被测服务读取时就自然拿到 mock 数据：

1. API 测试：挂载 fixtures/mock_api_responses 到容器内 /app/stubs/，服务代码通过 ReadFile("/app/stubs/user_404.json") 加载响应
2. 配置测试：挂载 fixtures/config/test.env 到 /etc/app/config.env，应用启动时按约定路径加载
3. 数据库测试：挂载 fixtures/db/dump.sql 到容器内固定路径，配合初始化脚本自动导入

配合脚本实现一键切换桩集

不同测试场景可能需要不同桩组合（如网络异常 vs 正常流程），可用 shell 脚本管理：

1. 定义多个桩子目录：fixtures/stubs/v1_ok/、fixtures/stubs/v2_timeout/
2. 测试命令中用变量控制挂载路径：docker run -v $(pwd)/fixtures/stubs/v2_timeout:/app/stubs ...
3. CI 中通过环境变量选择：STUB_SET=v2_timeout make test

避免硬编码路径，提升可复用性。

注意隔离性与清理

Bind Mount 是双向实时同步的，测试过程若意外修改了桩文件，会影响后续测试：

1. 推荐将桩目录设为只读：docker run -v $(pwd)/fixtures:/app/stubs:ro ...
2. 不要让被测程序有写权限，防止污染源数据
3. CI 环境中建议每次拉取干净 Git 工作区，避免本地残留改动干扰

真正需要动态行为模拟（比如根据请求参数返回不同响应）时，Bind Mount 不够用，应搭配轻量 HTTP stub 服务（如 WireMock、Mockoon）或改用接口 mock + 依赖注入。