不能直接调用真实接口，因其依赖网络和第三方服务状态，导致测试不稳定、缓慢且难覆盖异常分支；应通过接口抽象、依赖注入、httptest.Server 或 fake 实现隔离。
为什么不能直接在测试里调用真实接口
真实接口依赖网络、第三方服务状态、数据一致性，会导致测试不稳定、速度慢、无法覆盖异常分支。比如 http.Get("https://api.example.com/users") 在 CI 环境可能超时或返回 404，测试就挂了，但问题未必出在你的代码上。
Mock 的核心目标不是“假装有返回”，而是“控制输入输出，隔离依赖”。Golang 没有运行时反射式 Mock 框架（如 Java 的 Mockito），所以必须从设计入手——提前把接口依赖抽象成可替换的变量或参数。
- 真实 HTTP 调用必须封装进一个可注入的函数或结构体方法，不能硬编码在业务逻辑里
- 避免在 struct 方法中直接 new http.Client()；应通过字段或构造函数传入
- 接口定义要小而具体，比如
type UserFetcher interface { GetByID(id string) (*User, error) }，而不是大而全的Service接口
用 httptest.Server 替换真实 HTTP 请求
这是最常用也最轻量的方式，适合测试调用外部 HTTP API 的 client 代码。它启动一个本地临时服务器，返回你预设的响应，不走网络，完全可控。
关键点：把 client 的 base URL 抽出来作为可配置项，测试时指向 httptest.Server.URL。
立即学习“go语言免费学习笔记（深入）”；
func TestFetchUser(t *testing.T) {
server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if r.URL.Path != "/users/123" || r.Method != "GET" {
t.Fatal("unexpected request")
}
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusOK)
json.NewEncoder(w).Encode(map[string]interface{}{"id": "123", "name": "Alice"})
}))
defer server.Close()
<pre class="brush:php;toolbar:false;">client := &UserClient{BaseURL: server.URL} // 注意这里注入
user, err := client.GetByID("123")
if err != nil {
t.Fatal(err)
}
if user.Name != "Alice" {
t.Errorf("expected Alice, got %s", user.Name)
}}
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 务必调用
defer server.Close()，否则端口泄漏，多次运行测试会失败 - 不要用
server.URL + "/users/123"拼接路径，应统一由 handler 处理路由匹配，避免测试和实际行为不一致 - 如果被测代码用了自定义
http.Transport（比如设置了 timeout），记得在测试 client 中复现，否则可能漏掉超时逻辑的验证
用 interface + fake 实现依赖隔离
当依赖不是 HTTP，而是数据库、缓存、消息队列等，或者你想彻底绕过网络层做单元测试，就该用 Go 原生方式：定义接口，写 fake 实现，测试时注入。
例如，业务逻辑依赖一个用户存储：
type UserStore interface {
Save(u *User) error
FindByID(id string) (*User, error)
}
<p>// 生产实现
type SQLUserStore struct{ db <em>sql.DB }
func (s </em>SQLUserStore) Save(u <em>User) error { /</em> ... */ }</p><p>// 测试用 fake
type FakeUserStore struct {
Users map[string]<em>User
}
func (f </em>FakeUserStore) Save(u <em>User) error {
if f.Users == nil {
f.Users = make(map[string]</em>User)
}
f.Users[u.ID] = u
return nil
}
func (f <em>FakeUserStore) FindByID(id string) (</em>User, error) {
u, ok := f.Users[id]
if !ok {
return nil, errors.New("not found")
}
return u, nil
}- fake 不需要模拟所有行为，只实现当前测试用到的方法即可；未覆盖路径应 panic 或返回明确错误，避免静默失败
- 避免在 fake 中引入时间、随机数、全局状态等不可控因素；比如
time.Now()应抽成可注入的函数字段 - 如果多个测试共用一个 fake 实例，注意清空状态（如
f.Users = make(map[string]*User)），否则测试间会互相污染
gomock 和 testify/mock 的适用边界
gomock 是官方维护的 mock 工具，testify/mock 是社区常用替代。它们都生成实现了指定 interface 的 mock struct，并支持预期调用校验（如“必须被调用 2 次，参数为 X”）。
但它们解决的是“验证交互行为”，不是“替换依赖”。你依然得把 interface 作为参数传入，否则生成的 mock 根本用不上。
- 适合场景：需要断言“某依赖方法是否被调用”“是否以特定顺序被调用”“是否收到特定参数”，比如审计日志、事件触发、重试逻辑
- 不适合场景：只想让测试跑通、不关心调用过程；或者 interface 方法太多，生成 mock 成本高且易过时
- gomock 生成的 mock 是强类型的，但要求 interface 必须导出；如果 interface 在内部包定义，需调整可见性或改用手工 fake
真正容易被忽略的是：mock 工具不能弥补糟糕的接口设计。如果一个 interface 有 12 个方法，但每次测试只用其中 1 个，说明它违反了接口隔离原则——拆分才是根本解法。
