Go测试中不能直接new依赖，因真实依赖破坏隔离性、速度和可重复性；应通过接口抽象行为并手写函数式mock，或按需选用gomock/testify，HTTP场景优先考虑httptest.Server。
Go 测试中为什么不能直接 new 依赖？
因为真实依赖（比如数据库、HTTP 客户端、文件系统）会破坏测试的隔离性、速度和可重复性。单元测试要快、确定、不依赖外部状态，new 一个 *sql.DB 或 http.Client 会导致测试启动慢、失败不可控、CI 环境难配置。
核心思路是：用接口抽象行为，再用 mock 实现该接口，让被测代码只依赖接口，不绑定具体实现。
常见错误现象：
— 测试里调 db.QueryRow() 报 connection refused
— 同一测试多次运行结果不一致（比如依赖当前时间或随机数）
— 测试耗时从毫秒级涨到秒级
用 interface + struct mock 最简可行方案
不需要第三方库也能 mock，前提是依赖已定义为接口。例如 HTTP 调用：
// 定义接口，而非直接依赖 *http.Client
type HTTPDoer interface {
Do(req *http.Request) (*http.Response, error)
}
func FetchUser(client HTTPDoer, id string) (string, error) {
req, _ := http.NewRequest("GET", "https://api.example.com/users/"+id, nil)
resp, err := client.Do(req)
if err != nil {
return "", err
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
return string(body), nil
}
测试时写个轻量 mock：
type MockHTTPDoer struct {
DoFunc func(*http.Request) (*http.Response, error)
}
func (m *MockHTTPDoer) Do(req *http.Request) (*http.Response, error) {
return m.DoFunc(req)
}
func TestFetchUser(t *testing.T) {
mockClient := &MockHTTPDoer{
DoFunc: func(req *http.Request) (*http.Response, error) {
return &http.Response{
StatusCode: 200,
Body: io.NopCloser(strings.NewReader(`{"name":"alice"}`)),
}, nil
},
}
name, err := FetchUser(mockClient, "123")
if err != nil {
t.Fatal(err)
}
if name != `{"name":"alice"}` {
t.Fail()
}
}
关键点：
— 接口必须由你控制（不能直接 mock *sql.DB，得先包装成 Querier 接口）
— mock struct 的字段最好是函数类型，便于测试中灵活替换行为
— 不要试图 mock 标准库未导出方法（如 http.Client.do），那是反模式
gomock 和 testify/mock 的适用边界
当接口方法多、调用顺序/次数有要求、或需要自动生成 mock 代码时，才值得引入工具。
gomock 适合大型项目，生成强类型 mock，但需额外运行 mockgen；testify/mock 更轻，基于反射，但编译期无类型检查，容易写错方法名。
本文档主要讲述的是maven使用方法；Maven是基于项目对象模型的（pom），可以通过一小段描述信息来管理项目的构建，报告和文档的软件项目管理工具。Maven将你的注意力从昨夜基层转移到项目管理层。Maven项目已经能够知道 如何构建和捆绑代码，运行测试，生成文档并宿主项目网页。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
容易踩的坑：
— 用 gomock mock 了接口，但被测代码仍传入真实实现（忘记替换构造参数）
— 在 test 文件里漏掉 mockCtrl.Finish()，导致期望未满足却不报错
— 为每个小函数都上 gomock，反而让测试更难读、更重
建议节奏：
— 先手写 mock 搞清依赖流
— 接口稳定且调用逻辑复杂（比如要验证三次 Put()、中间夹一次 Delete()）再切 gomock
— 避免 mock 第三方 SDK 的整个 client，优先 mock 你封装的一层 service 接口
HTTP 依赖的特殊处理：httptest.Server 更快更安全
如果被测代码硬编码用了 http.Get 或 *http.Client，又不想改接口，httptest.Server 是比 mock 更自然的选择。
它起一个真实但内存内的 HTTP 服务，完全绕过网络和 DNS，响应可控、无副作用：
func TestFetchUserWithHTTPServer(t *testing.T) {
server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(200)
w.Write([]byte(`{"id":"123","name":"bob"}`))
}))
defer server.Close() // 注意关闭
// 假设 FetchUser 内部用了 http.Get
resp, err := http.Get(server.URL + "/users/123")
if err != nil {
t.Fatal(err)
}
defer resp.Body.Close()
// ...断言逻辑
}
注意：
— httptest.Server 本质是集成测试风格，但它比连真实 API 快 100 倍以上，且不污染环境
— 不适用于需要模拟超时、连接中断等底层网络问题的场景（这时得用 net/http/httputil 或自定义 transport）
— 别在 benchmark 中用它，它仍有 goroutine 和 socket 开销
真正难的不是 mock 本身，而是识别哪些依赖该抽成接口、哪些该用 httptest、哪些其实该删掉（比如测试里还调了日志上报）。越早把“可测试性”当成接口设计的一部分，后面 mock 才不会变成补丁堆叠。
