如何在Golang微服务中做集成测试_多服务测试方法_技术教程

Testcontainers-go 是最稳妥的真实依赖集成测试方案，通过 Docker API 启动轻量容器并绑定生命
周期，需动态获取端口、添加健康检查、用 Wire 构建独立测试依赖图、跨服务调用加超时重试、按 schema 隔离数据库数据。

用 testcontainer 启动真实依赖服务

集成测试不是 mock 所有外部依赖，而是让被测服务连接真实的数据库、Redis、Kafka 等。硬编码本地端口或要求开发者预装服务，会导致 CI 失败、环境不一致。testcontainers-go 是目前最稳妥的选择——它通过 Docker API 启动轻量容器，生命周期绑定到 Go 测试函数。

必须在 TestMain 或每个 TestXxx 开头调用 testcontainers.RunContainer，并用 defer container.Terminate(ctx) 清理
PostgreSQL 容器暴露的端口需用 container.MappedPort 动态获取，不能写死 5432
启动后要加健康检查（比如轮询 PING Redis 或执行 SELECT 1），否则服务可能因依赖未就绪而启动失败
CI 中若用 GitHub Actions，需确保 runner 支持 Docker-in-Docker（docker://docker:dind）或使用 setup-docker action

ctx := context.Background()
req := testcontainers.ContainerRequest{
    Image:        "redis:7-alpine",
    ExposedPorts: []string{"6379/tcp"},
}
redisC, _ := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
    ContainerRequest: req,
    Started:        true,
})
port, _ := redisC.MappedPort(ctx, "6379")
redisAddr := fmt.Sprintf("localhost:%s", port.Port())
// 接着初始化你的 service 实例，传入 redisAddr

用 Wire 构建可替换的依赖图

微服务通常用 wire 管理依赖注入。集成测试时，你不能沿用生产 Wire Set——比如生产用 redis.NewClient，测试却要连 Docker Redis；数据库连接字符串也完全不同。关键是在测试包里定义独立的 WireSet，显式替换具体实现。

不要在 main.go 的 InitializeApp 里硬编码初始化逻辑，所有 newXXX 函数应提取为变量或接口
为测试单独建 app/testwire/wire.go，引入 testcontainer 启动的实例，并注入到 Service 构造中
避免在测试中直接修改全局变量或单例，Wire 的 compile-time 依赖图能防止“改一个测试，破十个”
如果服务间有 gRPC 调用，测试中可用 bufconn 模拟 server，但仅限于单元级；跨服务集成仍需真实 server 容器

跨服务调用的请求/响应断言要带超时和重试

两个服务都跑起来了，不代表它们能立刻通信。网络就绪、gRPC server 启动完成、HTTP 路由注册完毕，都有延迟。直接发请求然后断言响应，大概率遇到 connection refused 或空响应。

对 HTTP 服务，用 http.DefaultClient.Do + time.Sleep 不可靠，改用 retry.Do（如 github.com/avast/retry-go）封装请求
gRPC 客户端请设置 WithBlock() 和短超时（如 500ms），避免阻塞整个测试；连接失败时捕获 status.Code(err) == codes.Unavailable
断言响应体前，先检查 http.StatusCode 或 gRPC status.Code，再解析 JSON/Protobuf——很多失败源于状态码非 200 却强行解码
避免在测试中 sleep 固定秒数（如 time.Sleep(3 * time.Second)），它既拖慢测试，又无法覆盖慢机器场景