Go接口实现测试的核心是验证不同结构体是否满足同一接口契约，通过共享测试函数驱动多种实现，统一检查行为一致性而非实现细节，确保多态调用语义正确。
在 Go 中，接口实现测试的核心是验证不同结构体是否真正满足同一接口契约，确保多态调用时行为一致、符合预期。这不是单纯检查方法签名是否匹配，而是通过统一测试用例驱动多种实现，确认它们在相同输入下产生符合语义的输出。
定义清晰、可测的接口
接口应聚焦抽象行为，避免暴露实现细节。例如设计一个 PaymentProcessor 接口：
type PaymentProcessor interface {
Process(amount float64) error
Refund(amount float64) error
Status() string
}
每个方法都具备明确语义：Process 应完成扣款逻辑，Refund 应可逆操作，Status 应返回当前状态快照。接口越小、职责越单一，越容易写出通用测试用例。
为接口编写共享测试函数
不为每个实现单独写 TestXXX，而是写一个接收接口值的测试函数，供所有实现复用：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 函数签名形如 func TestPaymentProcessor(t *testing.T, p PaymentProcessor)
- 在函数内执行标准流程：正常支付 → 查询状态 → 部分退款 → 再查状态 → 验证状态变化与误差边界
- 对错误场景也统一覆盖：如 Process 负金额应返回 error，Refund 超出已支付金额应拒绝
用子测试（subtest）组织多实现验证
在主测试函数中，为每个具体实现创建子测试，传入其实例：
func TestAllPaymentProcessors(t *testing.T) {
t.Run("StripeProcessor", func(t *testing.T) {
TestPaymentProcessor(t, &StripeProcessor{})
})
t.Run("PayPalProcessor", func(t *testing.T) {
TestPaymentProcessor(t, &PayPalProcessor{})
})
t.Run("MockProcessor", func(t *testing.T) {
TestPaymentProcessor(t, &MockProcessor{FailOnRefund: true})
})
}
这样既复用逻辑，又隔离失败——某个实现挂了不影响其他测试，输出日志也自带上下文（如 “StripeProcessor” failed）。
关注行为一致性而非实现细节
测试中避免断言私有字段或内部状态，只观测接口暴露的行为：
- ✅ 正确：检查 Status() 返回是否包含 "paid" 或 "refunded"
- ✅ 正确：检查 Process(100) 后再 Refund(30)，最终余额是否为 70
- ❌ 错误：检查 StripeProcessor 的 client.APIKey 是否被设置
- ❌ 错误：断言错误类型是否为 stripe.Error —— 这属于实现绑定，应只断言 error != nil 和 error.Error() 包含关键词
真正的多态一致性，体现在“调用同一接口方法，得到符合业务语义的结果”，而不是结果完全相同（比如时间戳、ID 格式可以不同）。
