go 语言不鼓励对同结构体内的接收器函数进行 mock；推荐采用表驱动测试逐层验证各方法行为，或通过接口抽象依赖、注入不同实现来解耦外部副作用——这才是符合 go 习惯的可测性设计。
在 Go 中，试图 Mock 同一结构体内部的接收器函数（如 m.two() 调用 m.one()）不仅违背语言哲学，还会显著增加测试复杂度与维护成本。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
}{
{"basic", &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
}{
{"basic", &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)
}
})
}
}✅ 优势：
- 零依赖、零 Mock、零第三方库；
- 每个方法职责清晰，失败定位精准；
- 符合 Go 标准库测试风格（如 net/http, strings, time 包的测试）。
✅ 正确做法二：接口抽象 + 实现替换（适用于含 I/O 的真实场景）
当 one() 或 two() 实际涉及文件读写、数据库查询或网络请求时，不应在 Three() 测试中容忍这些副作用。此时应重构为依赖接口：
type OneAndTwoer interface {
one() int
two() int
}
// 生产实现
func (m *MyStruct) one() int { /* ... */ }
func (m *MyStruct) two() int { /* ... */ }
// 测试专用实现（非 Mock，而是轻量“存根”）
type StubOneTwo struct{ val int }
func (s StubOneTwo) one() int { return s.val }
func (s StubOneTwo) two() int { return s.val * 2 }
// 将 Three 提升为函数，接受接口
func Three(o OneAndTwoer) int {
return o.two() * 2
}
// 测试时直接传入 Stub
func TestThree(t *testing.T) {
tests := []struct {
name string
o OneAndTwoer
want int
}{
{"stub returns 3", StubOneTwo{3}, 18}, // 3 → 6 → 12? 等等：3.two()=6 → 6*2=12 → 修正为 12
{"stub returns 5", StubOneTwo{5}, 20},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := Three(tt.o); got != tt.want {
t.Errorf("Three() = %v, want %v", got, tt.want)
}
})
}
}⚠️ 注意事项：
- 不要为每个方法都创建构造函数或字段覆盖（如 func NewMockMyStruct(oneFn func() int)），这属于反模式；
- Go 中“Mock”本质是定义接口 + 提供可控实现，而非动态拦截方法调用；
- 所有测试代码（包括未导出方法调用）均可直接访问，无需反射或代码生成。
总结
Go 的测试哲学是：让代码易于测试，而不是让测试适配难测的代码。
- 纯逻辑？→ 表驱动测试全覆盖；
- 含外部依赖？→ 抽离接口，注入内存/模拟实现；
- 拒绝“为了 Mock 而 Mock”的复杂方案。
参考 Go 标准库源码中的 _test.go 文件（如 os/exec/exec_test.go, net/http/clientserver_test.go），你会发现几乎所有高质量 Go 项目都遵循这一路径——简单、可靠、且经得起大规模演进考验。
