go 语言鼓励通过表驱动测试验证每个方法的行为，而非 mock 接收器函数；当方法依赖外部资源时，应通过接口抽象和依赖注入实现可测试性，而非直接替换方法。
在 Go 中，Mock 接收器函数（如 m.two() 调用被替换成模拟实现）不仅违背语言设计哲学，还会显著增加维护成本、破坏封装性，并掩盖代码结构问题。与 Python 或 Java 不同，Go 的测试文化强调真实行为验证 + 小步重构 + 接口解耦，而非运行时方法劫持。
✅ 正确做法一：分层表驱动测试（适用于纯逻辑方法）
对你的示例，one、two、Three 均为无副作用的纯计算方法，应独立、完整地测试：
func TestMyStruct_One(t *testing.T) {
tests := []struct {
name string
m MyStruct
want int
}{
{"basic", MyStruct{}, 2},
// 可扩展更多场景（如字段影响逻辑时）
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := tt.m.one(); got != tt.want {
t.Errorf("one() = %v, want %v", got, tt.want)
}
})
}
}
func TestMyStruct_Two(t *testing.T) {
tests := []struct {
name string
m MyStruct
want int
}{
{"calls one", MyStruct{}, 4}, // 2 * 2
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := tt.m.two(); got != tt.want {
t.Errorf("two() = %v, want %v", got, tt.want)
}
})
}
}
func TestMyStruct_Three(t *testing.T) {
tests := []struct {
name string
m MyStruct
want int
}{
{"calls two", MyStruct{}, 8}, // 2 * 2 * 2
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := tt.m.Three(); got != tt.want {
t.Errorf("Three() = %v, want %v", got, tt.want)
}
})
}
}✅ 优势：
- 零额外依赖，符合 Go 标准测试范式；
- 方法间调用链自然覆盖，无需 Mock 即可验证集成行为；
- 易于调试、稳定可靠、文档性强（测试即示例）。
✅ 正确做法二：接口抽象 + 依赖注入（适用于含 IO 的真实场景）
若 one() 或 two() 实际涉及数据库查询、HTTP 调用等不可控依赖，则不应让 Three() 直接耦合 MyStruct 的具体实现，而应提取接口：
type OneAndTwoer interface {
one() int
two() int
}
// Three 独立于具体类型，仅依赖接口
func Three(o OneAndTwoer) int {
return o.two() * 2
}
// 生产代码中使用
func (m *MyStruct) Three() int {
return Three(m) // 委托给纯函数
}
// 测试时提供轻量实现
type mockOneTwo struct{ val int }
func (m mockOneTwo) one() int { return m.val }
func (m mockOneTwo) two() int { return m.val * 2 }
func TestThree_WithMockImpl(t *testing.T) {
got := Three(mockOneTwo{val: 3})
if got != 12 { // 3 → one=3 → two=6 → Three=12
t.Errorf("Three() = %v, want 12", got)
}
}⚠️ 注意：这不是“Mock”，而是面向接口的多态实现——Go 标准库（如 io.Reader/http.ResponseWriter）大量采用此模式，清晰、安全、无反射风险。
❌ 不推荐的做法（为什么应避免）
- 为每个方法手动构造带函数字段的结构体（如 func() int 类型字段）并重写调用逻辑：破坏类型安全，增加冗余字段，使结构体职责混乱；
- 使用 unsafe 或反射动态替换方法：违反 Go 的可读性与可维护性原则，且在新版本中极易失效；
- 引入第三方 Mock 库（如 gomock）：Go 官方明确不鼓励，标准库测试实践中几乎从不使用。
总结
Go 的测试之道是：
? 优先测试真实行为——用表驱动覆盖所有输入输出；
? 必要时解耦依赖——通过小而专注的接口隔离不稳定性；
? 拒绝“为了 Mock 而 Mock”——那往往意味着设计需要重构。
参考 net/http, os, io 等标准库包的 _test.go 文件，你会发现：最健壮的 Go 测试，通常由干净的接口、简单的结构体和详尽的表格组成——而不是复杂的 Mock 层。
