依赖注入通过 interface 解耦外部依赖,使 Go 单元测试无需打桩全局状态;Option 模式应避免副作用,init() 和包级变量须移出以保障测试隔离;装饰器需覆盖短路逻辑并注入可模拟依赖。
Go 单元测试不再需要打桩全局状态Go 语言没有类继承和虚函数机制,传统面向对象设计模式(如模板方法、策略)常被误用为“强行套用”,反而增加测试负担。真正影响单元测试质量的
,是能否把被测逻辑与外部依赖解耦。interface + 依赖注入是最自然的解法。
比如一个发送邮件的服务,如果直接在函数里调用 smtp.Send(),测试时就得连真实 SMTP 服务器或写复杂 mock;但若定义 type EmailSender interface { Send(to, body string) error },并在构造函数中注入实现,测试时只需传入一个满足该接口的匿名结构体:
func TestSendNotification(t *testing.T) {
var capturedTo, capturedBody string
mockSender := &mockEmailSender{
sendFunc: func(to, body string) error {
capturedTo, capturedBody = to, body
return nil
},
}
svc := NewNotificationService(mockSender)
svc.Notify("user@example.com", "hello")
if capturedTo != "user@example.com" {
t.Error("expected to address")
}
}
interface 天然支持鸭子类型http.DefaultClient),防止测试间污染var db *sql.DB),会导致测试必须重置状态或串行执行Option 模式让构造函数可测试且无副作用Go 中常见用 Option 函数配置结构体行为(如 WithTimeout(30*time.Second))。这类模式本身不影响测试,但若选项函数修改了全局状态或隐式初始化资源(如启动 goroutine、打开文件),就会让测试变得脆弱。
正确做法是:所有 Option 只设置字段,延迟到 Run() 或 Start() 等显式方法中触发副作用。
WithLogger(log.New(os.Stderr, "", 0)) 看似无害,但如果内部直接调用 log.SetOutput(),就污染了其他测试的日志输出Print() 方法,测试时传入 io.Discard 或内存 bufferassert.Equal(t, 30*time.Second, s.timeout)),而非验证副作用是否发生init() 和包级变量,否则测试无法隔离很多 Go 项目在 init() 函数里注册 handler、初始化缓存或连接数据库。这会让单元测试失去控制权——你无法在每次测试前重置它,也无法模拟失败路径(比如网络不可达)。
http.HandleFunc("/api", handler) 放在 init() 里,导致多个测试共用同一 mux,路由冲突或 panic*http.ServeMux 或 http.Handler,测试时传入干净实例var cache = newCache() 应改为构造函数参数,或至少提供 SetCacheForTest() 这样的覆盖入口(仅限测试)Go 中常用中间件风格的装饰器(如 func(h http.Handler) http.Handler)做日志、认证等。它们本身便于组合,但测试时容易只测“happy path”,忽略装饰器提前返回的情况。
例如一个 AuthMiddleware 在 token 无效时直接写 http.Error(w, "unauthorized", 401) 并 return,若测试只检查最终 handler 是否被调用,就漏掉了这个短路逻辑。
*http.Request
httptest.NewRecorder() 捕获响应状态码和 body,不能只断言 handler 执行次数最常被忽略的是:设计模式本身不提升可测性,只有配合明确的依赖边界、无隐藏状态、无全局副作用,才真正降低单元测试成本。写完一个 interface 不代表可测,得看它是否真的隔离了变化点。