Go中如何Mock内部（深层）函数以实现测试？

Go 本身不支持直接Mock普通函数，因为Mock库（如testify/mock）主要针对接口方法设计。要实现需求，需通过依赖注入或函数变量替换两种方式改造代码，以下是具体实现方案：

方案一：接口抽象+依赖注入（推荐） #

通过将普通函数封装为接口方法，让业务结构体依赖该接口，测试时传入Mock实现。

修改后的 main.go #

// 定义抽象接口
type ResponseProvider interface {
    ToMockResponse(hello string) error
}

// 业务结构体，依赖ResponseProvider接口
type Crs struct {
    RespProvider ResponseProvider
}

func (cr *Crs) TheFunction() error {
    // 调用接口方法而非直接调用普通函数
    err := cr.RespProvider.ToMockResponse("hello")
    return err
}

// 生产环境的实际实现
type RealResponseProvider struct{}

func (r *RealResponseProvider) ToMockResponse(hello string) error {
    return someError // 原有的错误返回逻辑
}

对应的 main_test.go #

import (
    "testing"
    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/mock"
)

// 实现Mock结构体，满足ResponseProvider接口
type MockResponseProvider struct {
    mock.Mock
}

func (m *MockResponseProvider) ToMockResponse(hello string) error {
    args := m.Called(hello)
    return args.Error(0)
}

func TestTheFunction(t *testing.T) {
    // 创建Mock实例并设置期望
    mockResp := new(MockResponseProvider)
    mockResp.On("ToMockResponse", "hello").Return(nil)
    
    // 向Crs注入Mock依赖
    cr := &Crs{RespProvider: mockResp}
    
    // 执行测试
    err := cr.TheFunction()
    assert.NoError(t, err)
    
    // 验证Mock方法是否按预期被调用
    mockResp.AssertExpectations(t)
}

方案二：全局函数变量替换（轻量方案） #

将普通函数定义为全局变量，测试时临时替换变量指向的实现。

修改后的 main.go #

type Crs struct{}

// 将原函数定义为全局变量
var ToMockResponseFunc = func(hello string) error {
    return someError // 原有的错误返回逻辑
}

func (cr *Crs) TheFunction() error {
    // 调用函数变量
    err := ToMockResponseFunc("hello")
    return err
}

对应的 main_test.go #

import (
    "testing"
    "github.com/stretchr/testify/assert"
)

func TestTheFunction(t *testing.T) {
    // 保存原函数实现，测试后恢复避免影响其他测试
    originalFunc := ToMockResponseFunc
    defer func() { ToMockResponseFunc = originalFunc }()
    
    // 替换为Mock实现
    ToMockResponseFunc = func(hello string) error {
        return nil
    }
    
    // 执行测试
    cr := &Crs{}
    err := cr.TheFunction()
    assert.NoError(t, err)
}

方案对比 #

• 方案一：符合依赖注入设计原则，扩展性强，适合复杂业务场景，支持多实例隔离。
• 方案二：实现简单，代码改动小，但全局变量存在并发测试风险，需注意测试隔离。

内容的提问来源于stack exchange，提问作者DevFromI