Go 测试如何稳定验证并发事件：WaitGroup、通道收口与超时断言

并发测试最容易让人误判的，不是业务断言写错，而是测试本身没有一个明确的收口点：生产协程还没发完，测试就开始读；通道没人关闭，range 一直等；超时分支又没有把现场信息留下来。把这三个边界拆开，Go 的 WaitGroup、通道关闭和 select 超时就能组成一套稳定的验收写法。

先把“并发完成”拆成两个可验收的动作

假设被测函数启动多个 worker，最后把处理结果送进一个通道。这里其实有两个不同问题：worker 是否全部结束，以及结果通道是否已经读空。只等待前者，可能漏掉缓冲区中的最后几条消息；只读通道，又可能在没人关闭它时永远阻塞。

因此测试里的最小配方是：生产端调用 wg.Done()，单独的收口协程等待 wg.Wait() 后关闭通道，测试协程只消费通道。关闭动作只有一个拥有者，责任链才不会互相踩脚。

用 WaitGroup 等生产者，用关闭通道等结果

下面的示例让三个 worker 各自上报一个事件。测试不依赖 goroutine 的执行顺序，只核对最终事件集合；这样即使调度顺序变化，断言仍然稳定。

package event_test

import (
    "fmt"
    "sort"
    "sync"
    "testing"
    "time"
)

func emitEvents(ids []int) 

这里的可见成功状态是测试函数能够从 range 正常退出，并且排序后的三条事件完整匹配。排序只用于消除调度顺序，不应掩盖重复事件或缺失事件，所以实际项目还可以先按事件 ID 建 map，再检查数量。

给等待链加超时，失败时保留现场

通道收口正确时，超时不会被触发；一旦被测代码忘记调用 Done、提前返回或漏关通道，测试不能让 CI 无限挂住。把收集动作放进一个 goroutine，用 time.After 给它加边界，并把已收集内容带进错误信息。

func collectWithTimeout(ch 

超时值应该覆盖正常测试的最大合理耗时，而不是越大越保险。纯内存 worker 通常可以用几十毫秒级别；如果测试依赖网络、磁盘或外部进程，应把等待边界作为测试参数，并在错误中说明具体阶段。

三个常见坑：顺序、关闭权和测试泄漏

不要在消费者侧“顺手”关闭一个仍可能被其他 worker 写入的通道，这会把偶发缺陷变成 send on closed channel。也不要在超时后直接结束测试而不处理收集 goroutine；被测函数最好接收 context.Context，超时路径先取消上下文，再等待资源退出。

把断言写成可重复运行的检查

并发测试的断言顺序建议固定为：先确认错误为空，再确认事件数量，最后确认每个事件的关键字段。涉及时间戳时，不要直接比较纳秒值；检查时间窗口、单调性或业务状态更可靠。对重复事件，可以用 map 计数，把“缺失”和“重复”分开报出来。

func checkEvents(t *testing.T, got []string) {
    t.Helper()
    counts := map[string]int{}
    for _, event := range got {
        counts[event]++
    }
    for _, want := range []string{"worker-1:done", "worker-2:done", "worker-3:done"} {
        if counts[want] != 1 {
            t.Errorf("event %q count = %d, want 1; all=%v", want, counts[want], got)
        }
    }
}

相关问题

WaitGroup 能不能直接替代关闭通道？

不能。它只表示计数归零，不会让通道上的接收操作结束。需要由等待者在 wg.Wait() 返回后关闭通道。

为什么不直接固定读取三次？

固定次数适合结果数量永远严格不变的极小单元测试，但它无法覆盖提前少发、重复发送和通道未关闭。读到关闭更能验证并发流程的完成语义。

超时后怎样避免测试留下 goroutine？

让生产逻辑接收可取消的 context.Context，超时时调用取消函数，并确保发送使用带取消分支的 select。测试结束后可配合 go test -race 检查数据竞争。

最后的验收清单

• 每个启动的 worker 都有一次对应的 Done，且 Add 发生在启动前。
• 只有发送方的统一收口协程关闭结果通道。
• 断言不依赖 goroutine 调度顺序，超时信息能说明等待阶段。
• 修改并发代码后至少运行 go test -race ./...，再重复运行目标测试。