第1章 理解Compose测试环境：定义、作用、与Docker Compose的关系、核心组件、典型使用场景
1.1 定义：什么是Compose测试环境
Compose测试环境是一种基于Docker Compose构建的、专为测试场景设计的可编程、可重复、可销毁的多容器运行环境。它将“环境即代码”（Environment as Code）理念引入测试领域，通过声明式YAML配置统一管理被测应用、依赖服务、网络拓扑、数据卷及环境变量，使测试环境在 CI/CD 流水线中可被精确复制、快速拉起并在测试结束后自动清理。
- 可编程：环境定义全部纳入版本管理，随代码库一起演进。
- 可重复：相同的 Compose 配置在任意宿主机上产出完全一致的容器拓扑。
- 可销毁：测试完成后通过一条命令即可回收所有资源，避免“环境残留”污染后续测试。
核心公式：
Compose测试环境 = Docker Compose（编排引擎） + 测试夹具（数据/配置/脚本） + 生命周期自动化（启动→就绪→测试→清理）
Compose测试环境 = Docker Compose（编排引擎） + 测试夹具（数据/配置/脚本） + 生命周期自动化（启动→就绪→测试→清理）
1.2 作用与价值
| 维度 | 作用 | 技术收益 |
|---|---|---|
| 环境一致性 | 消除“在我机器上能跑”的偏差 | 开发者、CI、预发环境共享同一份 Docker Compose 配置 |
| 依赖隔离 | 每个测试套件使用独立的容器沙箱 | 避免端口冲突、数据污染和并行测试干扰 |
| 快速反馈 | 秒级启动完整依赖栈 | 集成测试反馈周期从分钟级缩短到秒级 |
| 资源可观测 | 暴露健康检查、日志、指标端点 | 测试失败时可精准定位是环境故障还是业务缺陷 |
| 自动化集成 | 无缝嵌入 GitLab CI / GitHub Actions / Jenkins | 无需人工干预即可在流水线中拉起/销毁环境 |
1.3 与 Docker Compose 的关系
Compose测试环境不是Docker Compose 的替代品，而是在 Docker Compose 之上构建的测试专用层。两者关系可通过下表理解：
| 对比维度 | Docker Compose | Compose 测试环境 |
|---|---|---|
| 定位 | 通用多容器编排工具 | 测试场景专用环境框架 |
| 配置粒度 | 关注服务定义、网络、卷 | 额外包含测试夹具、种子数据、健康断言 |
| 生命周期 | 由用户手动 up/down 管理 | 自动化：启动→就绪等待→测试→清理 |
| 典型文件 | docker-compose.yml |
docker-compose.test.yml + 夹具脚本 + 测试配置 |
| 输出产物 | 运行中的应用服务 | 测试报告 + 可复现的环境快照 |
实践建议：在仓库中同时维护
docker-compose.yml（开发用）和 docker-compose.test.yml（测试用），测试配置通过 extends 或 profiles 继承开发配置并覆盖测试专属参数，避免配置重复维护。
1.4 核心组件
Compose测试环境由以下六大核心组件构成，它们协同工作以提供稳定、可复现的测试基础设施：
| 组件 | 职责 | 配置示例（YAML片段） |
|---|---|---|
| 服务定义 | 声明容器镜像、端口映射、依赖关系 | image: postgres:15\nports: - "5432" |
| 网络配置 | 控制容器间通信隔离与 DNS 解析 | networks:\n test-net:\n driver: bridge |
| 数据卷 | 持久化测试数据与共享夹具文件 | volumes:\n pgdata:\n - ./fixtures:/seed |
| 环境变量 | 参数化数据库连接串、密钥、日志级别 | environment:\n DB_URL: jdbc:postgresql://db:5432/test |
| 健康检查 | 验证依赖服务是否就绪 | healthcheck:\n test: ["CMD", "pg_isready"]\n interval: 2s |
| 生命周期钩子 | 在启动/停止前后执行夹具脚本 | x-test-hooks:\n pre-up: ./seed.sh\n post-down: ./clean.sh |
1.5 典型使用场景
Compose测试环境在以下四类场景中发挥关键作用，每个场景都对应一套可复用的配置模板：
- 集成测试（Integration Testing）
被测服务需要真实数据库、消息队列或缓存实例。Compose 定义完整依赖栈，测试容器通过内部网络直接访问。 - 数据库迁移测试（Migration Testing）
使用临时数据卷加载特定版本的 schema 和种子数据，验证迁移脚本在干净或已有数据集上的行为。 - 端到端 API 测试（E2E API Testing）
启动被测 API 容器 + 测试执行器容器，测试脚本通过depends_on与健康检查确保环境就绪后再发起请求。 - CI/CD 流水线集成（Pipeline Integration）
在 GitLab CI / GitHub Actions 中直接调用docker compose -f docker-compose.test.yml up --abort-on-container-exit，测试结束后自动销毁环境。
常见陷阱：不要在生产 Compose 文件上直接运行测试。生产配置通常包含持久卷、生产端口映射和资源限制，这些会干扰测试隔离性。始终为测试维护独立的
docker-compose.test.yml 或使用 --profile 隔离测试专用服务。
1.6 最小可运行测试环境示例
以下 YAML 定义了一个包含 PostgreSQL 数据库和 测试执行器的最小 Compose 测试环境。该配置将在后续章节中作为基线逐步扩展：
version: "3.8"
services:
db:
image: postgres:15-alpine
environment:
POSTGRES_DB: testdb
POSTGRES_USER: tester
POSTGRES_PASSWORD: testpass
healthcheck:
test: ["CMD-SHELL", "pg_isready -U tester -d testdb"]
interval: 2s
timeout: 2s
retries: 10
ports:
- "5432"
networks:
- test-net
volumes:
- pgdata:/var/lib/postgresql/data
- ./fixtures/seed.sql:/docker-entrypoint-initdb.d/seed.sql
test-runner:
image: python:3.11-slim
depends_on:
db:
condition: service_healthy
environment:
DB_HOST: db
DB_PORT: 5432
DB_NAME: testdb
DB_USER: tester
DB_PASS: testpass
command: >
sh -c "pip install pytest psycopg2-binary &&
pytest -v /tests"
volumes:
- ./tests:/tests
networks:
- test-net
volumes:
pgdata:
networks:
test-net:
driver: bridge启动与执行命令：
# 启动测试环境（后台运行）
docker compose -f docker-compose.test.yml up -d
# 手动触发测试（若 test-runner 未自动执行）
docker compose -f docker-compose.test.yml run --rm test-runner
# 查看测试日志
docker compose -f docker-compose.test.yml logs test-runner
# 销毁环境并删除卷（清理测试数据）
docker compose -f docker-compose.test.yml down -v
关键设计点：
•
•
•
•
healthcheck 确保 test-runner 不会在数据库尚未就绪时启动。•
depends_on 配合 condition: service_healthy 实现精准的就绪等待。•
down -v 中的 -v 标志会删除匿名卷，确保下次运行环境完全干净。