集成测试需用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") 获取后再启动服务。
