Go测试如何mock函数_Go函数Mock实现方式

Go中不能直接mock普通函数，必须将其抽象为接口或函数类型字段后注入，如定义SMSService结构体含sendFunc字段并在测试时替换为桩函数。

Go里不能直接mock普通函数，必须重构为可注入接口

Go语言本身不支持像Python或JavaScript那样对顶层函数做运行时替换。mock普通函数（比如http.Get、time.Now、自定义的sendEmail）在Go中本质是“不可行”的——编译器会把函数调用静态绑定到符号地址，无法拦截或替换成桩实现。

真正可行的做法是：把依赖的函数行为抽象成接口，再通过参数或结构体字段注入。常见模式包括：

• 将函数类型定义为字段，例如 type Service struct { HTTPDo func(...){} }
• 定义接口（如 type HTTPClient interface { Do(req *http.Request) (*http.Response, error) }），用 &http.Client{} 或 mock 实现满足它
• 把函数作为参数传入，比如 func Process(ctx context.Context, fetcher func(string) ([]byte, error)) error

用函数字段+struct实现轻量级mock（适合单元测试）

不需要引入第三方库，靠Go原生语法就能完成干净的函数mock。核心是把外部依赖“抬升”为结构体字段，在测试时赋值为闭包或桩函数。

示例场景：一个发送短信的服务，依赖底层 sendSMS 函数：

type SMSService struct {
	sendFunc func(phone, msg string) error
}

func NewSMSService() *SMSService {
	return &SMSService{
		sendFunc: sendSMS, // 生产环境用真实函数
	}
}

func (s *SMSService) Send(to, content string) error {
	return s.sendFunc(to, content)
}

// 测试时
func TestSMSService_Send(t *testing.T) {
	svc := NewSMSService()
	svc.sendFunc = func(phone, msg string) error {
		if phone == "13800138000" {
			return nil
		}
		return errors.New("invalid phone")
	}

	err := svc.Send("13800138000", "hello")
	if err != nil {
		t.Fatal(err)
	}
}

注意：sendFunc 字段必须是导出的（首字母大写），否则测试包无法赋值；真实函数 sendSMS 需要定义在同包下且可被引用。

mock标准库函数（如time.Now、rand.Intn）的惯用法

标准库函数无法重写，但几乎所有这类函数都提供了“可替换”的变体或封装入口：

• time.Now → 改用 time.Now 的包装，例如定义 type Clock interface { Now() time.Time }，并在结构体中持有 Clock 字段；生产用 realClock{}，测试用 fixedClock{t: fixedTime}
• rand.Intn → 不要用全局 rand，改用 rand.New(rand.NewSource(seed)) 实例，把 *rand.Rand 作为字段或参数传入
• os.ReadFile → 抽象为 type FileReader interface { ReadFile(name string) ([]byte, error) }，测试时返回预设字节或错误

关键点：不是“mock函数”，而是“控制依赖的实例化时机和来源”。标准库设计者早已预留了这种扩展性，只是需要你主动使用。

第三方库如gomock只适用于接口，对函数无能为力

gomock 是 Google 官方维护的 mock 工具，但它只生成接口的 mock 实现（mock_.go），完全不处理函数类型。如果你试图对函数签名生成 mock，mockgen 会报错或静默跳过。

类似地，testify/mock、gomock、go-sqlmock 全部基于接口契约。想用它们，第一步永远是定义接口 —— 这不是额外负担，而是Go测试友好的必然路径。

容易踩的坑：

• 试图用 monkey.Patch 等运行时补丁库 → 在 Go 1.18+ 中因 unsafe 限制和模块校验基本失效，且破坏 test parallelism
• 把函数 mock 写在 init() 或包变量里 → 导致测试间污染，尤其在 go test -race 下极易出错
• 忘记在测试结束前恢复原始函数（如果用了非推荐方式）→ 后续测试行为异常，难以定位

最稳妥的方式始终是：让函数成为可变依赖，而不是试图篡改它。