如何使用Golang table-driven并发测试_组合多数据和协程场景

table-driven测试与并发结合即为每组测试用例启动多个goroutine，并通过channel和WaitGroup收集结果、校验全局状态；需用atomic/sync保护共享资源，运行时加-race标志检测竞态。

理解 table-driven 测试与并发的结合点

Go 中的 table-driven 测试本质是用结构体切片定义多组输入、预期和上下文，让测试逻辑复用；而并发测试的关键在于验证函数在多个 goroutine 同时调用时的行为是否正确——比如是否发生竞态、数据是否一致、是否满足超时或重试约束。二者组合，就是为每组测试用例启动一批协程，并统一断言其结果集合或全局状态。

基础结构：定义测试表 + 并发执行器

先定义清晰的测试项结构，包含输入参数、期望结果、并发数（goroutines）、可选的超时控制：

type concurrentTestCase struct {     name     string     input    interface{}     wantErr  bool     wantData interface{} // 可选：用于比对返回值或共享状态     n        int         // 并发 goroutine 数量     timeout  time.Duration }

测试函数中遍历该表，对每个用例启动 n 个 goroutine，用 channel 收集结果，再统一校验：

• 用 sync.WaitGroup 等待所有 goroutine 完成
• 用 chan Error 或 chan result 汇总各协程输出
• 若涉及共享资源（如 map、计数器），确保加锁或使用 sync.Map/atomic
• 用 context.WithTimeout 控制整体执行时限，避免死锁卡住测试

处理共享状态与竞态检测

多数并发问题源于未保护的共享变量。例如测试一个计数器的并发安全：

立即学习“go语言免费学习笔记（深入）”；

func TestCounter_Concurrent(t *testing.T) {     tests := []concurrentTestCase{         {"increment-100", nil, false, 100, 100, 500 * time.Millisecond},         {"increment-50x2", nil, false, 100, 50, 500 * time.Millisecond},     } 
for _, tt := range tests {     t.Run(tt.name, func(t *testing.T) {         var counter int64         var wg sync.WaitGroup         errCh := make(chan error, tt.n)          for i := 0; i < tt.n; i++ {             wg.Add(1)             go func() {                 defer wg.Done()                 atomic.AddInt64(&counter, 1)             }()         }         wg.Wait()          if got := atomic.LoadInt64(&counter); got != int64(tt.wantData.(int)) {             t.Errorf("expected %d, got %d", tt.wantData, got)         }     }) }
} 
注意：真实场景中应避免直接操作裸 int，优先用 atomic 或 sync.Mutex；运行测试时务必加上 -race 标志：go test -race，它能自动捕获大部分数据竞争。
组合复杂场景：带依赖、重试、错误传播的并发测试
当被测函数含 I/O、网络调用或需重试逻辑时，测试表可扩展字段：

 setup 函数：为每个用例构造隔离的 mock 依赖（如内存 cache、fake DB client）
 teardown 函数：清理资源，避免用例间干扰
 expectCalls：预设 mock 应被调用次数，验证并发下是否重复/遗漏
用 testify/mock 或 gomock 搭配 sync.WaitGroup 控制 mock 行为时机

例如测试一个带指数退避的 http 客户端：表格中可设定“失败前重试 2 次”，然后启动 10 个协程，断言总请求次数为 10 × 3 = 30，且无 panic 或 goroutine 泄漏。