Golang高性能测试桩编写技巧

Go测试中优先用函数类型桩替代interface{}，轻量且避免过度抽象；需注意全局桩重置、HTTP客户端应注入而非修改DefaultClient、数据库慎用sqlmock而倾向内存实现、并发下桩状态须线程安全。

Go 测试中用 func 替换依赖比 interface{} 更轻量

直接用函数类型做桩，不强制抽象接口，能避开“为测试而接口”的设计负担。尤其适合工具类、纯逻辑函数（如 time.Now、rand.Intn）的替换。

常见错误是把桩写成全局变量却忘了在 TestMain 或每个 TestXxx 里重置，导致测试间污染。

• 用包级变量声明桩： var nowFunc = time.Now
• 测试中覆盖： nowFunc = func() time.Time { return time.Unix(123, 0) }
• 务必在 defer 中恢复原值，或用 t.Cleanup： t.Cleanup(func() { nowFunc = time.Now })
• 不要对方法接收者做函数赋值（比如 *http.Client.Do），Go 不允许直接赋值方法值，得封装成普通函数

Stub HTTP 客户端时别动 http.DefaultClient

改 http.DefaultClient 看似简单，但会污染整个进程，影响并行测试、pprof、甚至其他第三方库的 HTTP 调用。

正确做法是让被测代码接受一个可注入的 *http.Client，测试时传入 &http.Client{Transport: &http.Transport{RoundTrip: stubRoundTrip}}。

• stubRoundTrip 是实现 http.RoundTripper 的闭包，可按 URL 或 Header 返回预设响应
• 避免用 httptest.Server：它起真实 HTTP 服务，有端口占用、延迟、goroutine 泄漏风险；Stub Transport 零开销
• 注意 http.Client.Timeout 在 Stub 下仍会生效，若桩函数卡住，测试可能超时而非报错

数据库操作桩慎用 sqlmock，优先考虑内存实现

sqlmock 本质是拦截 database/sql 的驱动调用，对 SQL 语句做字符串匹配，极易因空格、换行、参数顺序等细节失败，且无法验证事务行为。

更稳的方式是让 DAO 层依赖 sql querier 接口（如 interface{ QueryRow(string, ...any) *sql.Row }），测试时传入内存实现（如用 map 模拟表）。

• 内存实现可精确控制返回 error 类型（如 sql.ErrNoRows vs 自定义 error），便于测分支逻辑
• sqlmock 的 ExpectQuery 默认区分大小写，SELECT 和 select 匹配失败——得加 sqlmock.QueryMatcherOption(sqlmock.QueryMatcherEqual)
• 若必须用 sqlmock，记得调用 mock.ExpectationsWereMet()，否则未命中的 expect 不报错

并发场景下 Stub 的状态必须线程安全

当被测代码启动 goroutine（如异步回调、定时重试），桩函数可能被多个 goroutine 同时调用。用普通 map 或计数器会 panic。

不是所有测试都跑在单 goroutine 里，尤其用了 t.Parallel() 或被测逻辑含 go 关键字时。

• 共享状态一律用 sync.Mutex 或 sync/atomic，例如记录调用次数： var callCount int64; atomic.AddInt64(&callCount, 1)
• 避免在桩函数里 sleep 或阻塞，这会让测试变慢且不可控；想模拟延迟，应在桩外控制（如用 time.AfterFunc 触发回调）
• 如果桩要返回不同结果（如第一次失败、第二次成功），用原子计数器 + switch，别用闭包捕获的局部变量——它在并发下不可靠

真正难的不是写桩，而是判断哪一层该被桩、哪一层该被集成。比如 JWT 解析逻辑用内存 key 桩就行，但 OAuth2 token 刷新流程，往往需要真实 HTTP 响应结构才能暴露边界问题——这时候 Stub 就该让位给最小化集成。