如何在Golang中进行集成测试_Golang多个模块接口测试方法

集成测试需用TestMain启动真实依赖服务并健康检查，测试后清理；模块间通过真实http调用验证契约；数据库用事务回滚防污染；CI中需显式启动依赖、端口探测和动态端口分配。

用 testmain 启动真实服务再跑测试

集成测试的核心是让被测模块与真实依赖（如数据库、HTTP 服务、消息队列）交互。golang 标准测试框架本身不提供启动/清理生命周期钩子，但可通过自定义 TestMain 控制流程。

关键点：不能只靠 go test 直接跑，必须在 TestMain 中启动依赖服务、等待就绪、运行测试、最后关闭。否则测试会因连接拒绝或超时失败。

• 所有依赖服务（如 postgresql、redis、mock HTTP server）应在 TestMain 的 m.Run() 前启动
• 使用 net.Listen 或 exec.Command 启动本地服务时，务必加健康检查（如轮询 /health 端点或尝试建连）
• 用 os.Exit(m.Run()) 结束，避免 defer 在 os.Exit 后不执行 —— 清理逻辑必须写在 m.Run() 之后、os.Exit 之前

func TestMain(m *testing.M) {     srv := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {         w.WriteHeader(200)         w.Write([]byte(`{"ok":true}`))     }))     srv.Start()     defer srv.Close() // 注意：这里 defer 无效！得手动放后面 
code := m.Run()  // 清理必须放这里 srv.Close() os.Exit(code)
}
模块间接口测试用 http.Client 调真实 endpoint
多个 Go 模块（比如 auth、order、payment）通过 HTTP 通信时，集成测试应绕过 mock，直接调用已启动的服务地址。重点不是测单个 handler，而是测模块组合行为是否符合契约。
立即学习“go语言免费学习笔记（深入）”；
常见错误：在测试里用 httptest.NewRequest + httptest.NewRecorder —— 这属于单元测试范畴，无法暴露跨模块的序列问题（如 auth Token 过期后 order 创建失败）。

每个模块的测试代码中，用 http.DefaultClient 或带 timeout 的自定义 client 发请求
服务地址不应硬编码，建议从环境变量读取：os.Getenv("AUTH_SERVICE_URL")，本地测试设为 http://localhost:8081 
必须校验 HTTP 状态码、响应 body jsON 字段、header（如 X-Request-ID 是否透传）

func TestOrderCreationWithAuth(t *testing.T) {     authURL := os.Getenv("AUTH_SERVICE_URL")     orderURL := os.Getenv("ORDER_SERVICE_URL") 
// Step 1: 获取 token resp, _ := http.Post(authURL+"/login", "application/json", strings.NewReader(`{"user":"test","pass":"123"}`)) defer resp.Body.Close() var authResp struct{ Token string } json.NewDecoder(resp.Body).Decode(&authResp)  // Step 2: 创建订单，带 token req, _ := http.NewRequest("POST", orderURL+"/orders", strings.NewReader(`{"item_id":123}`)) req.Header.Set("Authorization", "Bearer "+authResp.Token) client := &http.Client{Timeout: 5 * time.Second} resp2, _ := client.Do(req) if resp2.StatusCode != 201 {     t.Fatalf("expected 201, got %d", resp2.StatusCode) }
}
数据库状态污染导致测试不稳定
多个测试共用一个 PostgreSQL 实例时，INSERT 数据未清理会导致后续测试断言失败 —— 尤其当测试顺序偶然变化时，问题更隐蔽。
不要依赖 TRUNCATE 所有表（太慢、破坏外键约束），也不要在每个测试末尾 delete FROM（易漏、难维护）。推荐按测试用例粒度做事务回滚。

在 TestMain 或每个 TestXxx 开头，用 db.Begin() 启动事务
把 *sql.Tx 传给被测函数（需改接口），或用 sqlmock 拦截并重定向到事务对象
测试结束前调用 tx.Rollback() —— 成功或失败都回滚，确保零残留
注意：PostgreSQL 的 SAVEPOINT 不适用于并发测试，事务级隔离才是根本解法

CI 环境下依赖服务启动失败的排查路径
本地能过的集成测试，在 CI（如 gitHub Actions）里常卡在 “connection refused”。这不是代码问题，而是环境配置缺失。
典型原因：CI runner 默认不自动拉起 PostgreSQL 容器，也未等待端口就绪。docker Compose 的 depends_on 只等容器启动，不等服务 ready。

CI 配置里必须显式启动依赖服务，例如 github Actions 中用 services 块声明 postgres 并设置 ports 
测试代码中加端口探测逻辑，例如用 net.DialTimeout("tcp", "localhost:5432", 10*time.Second)，失败则重试 5 次
打印依赖服务日志（如 docker logs 或 pg_isready -h localhost -U testdb）比看 Go 测试 panic 更早定位问题
避免在测试里用 time.Sleep(2 * time.Second) 等待 —— 不可靠，且拖慢 CI

最易被忽略的是：不同模块的测试可能绑定同一端口（如都用 :8080），导致端口冲突。每个模块测试应动态分配空闲端口，用 net.Listen("tcp", ":0") 获取后再启动服务。