go 语言不鼓励通过 mock 接收器函数进行单元测试；推荐采用表驱动测试验证每个方法行为，并通过接口抽象依赖外部副作用的逻辑，从而实现可测、简洁且符合 go 习惯的测试方案。
在 Go 中，试图“Mock 接收器函数”（如 m.two() 被替换成模拟实现）不仅违背语言设计哲学，还会显著增加维护成本、掩盖设计问题，且官方工具链与标准库测试实践均不支持此类动态方法替换。与 Python 的 unittest.mock 或 Java 的 Mockito 不同，Go 的测试文化强调清晰的依赖边界和可组合的接口抽象，而非运行时方法拦截。
✅ 正确做法一：直接测试每个方法（推荐用于纯逻辑）
对于你示例中无副作用的 one()、two() 和 Three()，最自然、最可靠的方式是分别编写表驱动测试（table-driven tests）：
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) {
m := &MyStruct{}
// one() 已被验证正确，因此 two() 可安全基于真实 one() 测试
if got := m.two(); got != 4 {
t.Errorf("two() = %v, want 4", got)
}
}
func TestMyStruct_Three(t *testing.T) {
m := &MyStruct{}
if got := m.Three(); got != 8 {
t.Errorf("Three() = %v, want 8", got)
}
}✅ 优势：零额外抽象、零 mock 框架、测试即文档、易于调试、与 go test 完美集成。
✅ 正确做法二：提取接口 + 依赖注入（适用于含副作用场景）
当 one() 或 two() 实际涉及 I/O（如调用数据库、读文件、发 HTTP 请求）时，问题本质不是“如何 mock 方法”，而是职责耦合过重。此时应重构：将可变行为抽象为接口，并让 Three() 依赖该接口而非具体类型：
// 定义契约：谁负责提供 one() 和 two() 的行为？
type Calculator interface {
One() int
Two() int
}
// 原始结构体实现该接口（生产环境使用）
func (m *MyStruct) One() int { return 2 }
func (m *MyStruct) Two() int { return m.One() * 2 }
// Three 不再是接收器方法，而是独立函数，接受接口
func Three(c Calculator) int {
return c.Two() * 2
}
// 测试时提供轻量 mock 实现（非第三方库，仅几行代码）
type mockCalc struct{ val int }
func (m mockCalc) One() int { return m.val }
func (m mockCalc) Two() int { return m.val * 2 }
func TestThree_WithMockImpl(t *testing.T) {
tests := []struct {
name string
calc Calculator
want int
}{
{"base case", mockCalc{val: 2}, 8},
{"edge case", mockCalc{val: 0}, 0},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := Three(tt.calc); got != tt.want {
t.Errorf("Three(%v) = %v, want %v", tt.calc, got, tt.want)
}
})
}
}⚠️ 注意：这不是“mock 接收器”，而是定义明确依赖、提供可控实现——这正是 Go “组合优于继承”“接口即契约”思想的直接体现。
? 为什么不推荐构造函数注入/方法覆盖？
如问题中提到的“为每个方法写自定义构造器并覆盖方法”，会导致：
- 类型膨胀（大量 MyStructForTestOne, MyStructForTestTwo 等）；
- 破坏封装（需暴露内部字段或方法供覆盖）；
- 难以维护（新增方法需同步更新所有测试构造器）；
- 违反 Go 的最小惊讶原则（读者无法直观理解行为来源）。
? 参考权威实践
Go 标准库本身是最佳学习资源：
- net/http/httptest 提供 Server 和 Recorder 模拟 HTTP 环境；
- os/exec.CommandContext 支持 exec.Command = fakeCommand 替换（全局变量注入，仅限极少数场景）；
- io/ioutil（已迁至 io）中大量使用 bytes.Reader、strings.Reader 等内存实现替代文件 I/O。
? 总结：不要 Mock 方法，而要设计可测的接口；不要隐藏依赖，而要显式声明；不要追求“完全隔离”，而要追求“可控边界”。 Go 的测试力量，源于简洁的抽象和诚实的依赖，而非复杂的模拟机制。
