要写好一个可测试的golang微服务，关键在于1.使用依赖注入解耦逻辑，2.通过接口mock外部依赖。具体来说，应避免在函数内部硬编码依赖如数据库连接，而是在构造函数中传入依赖，使测试时能替换为mock实现；同时利用golang接口特性，自定义mock结构体模拟行为，无需复杂框架即可完成验证。此外，测试代码应遵循单一职责、复用setup逻辑，并采用table-driven方式覆盖多种输入场景，从而提升测试质量与维护性。
写好一个可测试的微服务，Golang 项目里最重要的两个点是依赖注入和mock 技巧。这两块做不好，测试就容易变成“形式主义”，甚至干脆没人愿意写了。
下面我会从实际出发，讲讲怎么用依赖注入来解耦逻辑，以及怎么 mock 接口和外部依赖，让测试真正跑得起来、测得全面。
依赖注入：别把结构体硬写死
很多新手写服务的时候喜欢直接在函数里 new 一个数据库连接或者某个 service 实例，比如：
立即学习“go语言免费学习笔记（深入）”；
func NewUserService() *UserService {
return &UserService{
db: connectToDB(),
}
}这样写虽然看起来没问题，但一到测试就麻烦了——你没法替换掉真实的 db 连接，只能让它连真实数据库，要么慢、要么不稳定。
正确的做法是把依赖通过构造函数传进来，也就是所谓的依赖注入（DI）：
type UserService struct {
db DBInterface
}
func NewUserService(db DBInterface) *UserService {
return &UserService{db: db}
}这样，在正式运行时你可以传入真正的数据库实现，在测试中就可以传入一个 mock 的假实现。
Mock 接口：别怕写 fake 实现
Golang 的接口很适合用来做 mock。只要你的业务逻辑调用了接口方法，那你在测试时就可以自己实现一个简单的 mock 版本。
举个例子，假设你有一个发送邮件的服务接口：
type EmailService interface {
Send(to, subject, body string) error
}在测试的时候，你不希望真的发邮件出去，那就可以写一个 mock 实现：
type MockEmailService struct {
Called bool
Err error
}
func (m *MockEmailService) Send(to, subject, body string) error {
m.Called = true
return m.Err
}然后在测试中使用它：
mockEmail := &MockEmailService{}
userService := NewUserService(mockEmail)
// 调用被测函数...
err := userService.SendWelcomeEmail("user@example.com")
// 验证是否调用成功
assert.NoError(t, err)
assert.True(t, mockEmail.Called)这种方式简单有效，不需要引入复杂的 mock 框架也能满足大多数场景。
测试结构建议：别把测试写成“复制粘贴”
写测试的时候有几个小建议：
- 每个测试函数只测一个行为，别想在一个测试里验证一堆东西。
- 初始化数据和 mock 放在 setup 函数里，可以复用也可以保持清晰。
- 使用 table-driven testing 来批量测试多种输入情况。
例如：
tests := []struct {
name string
input string
expected int
}{
{"case1", "abc", 3},
{"case2", "hello world", 11},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
got := myFunc(tt.input)
assert.Equal(t, tt.expected, got)
})
}这种结构清晰，扩展性强，也方便定位问题。
小技巧补充：这些地方容易忽略
- 如果你用了像
http.Client这样的标准库对象，记得 mock 它的 RoundTripper，而不是整个 client。 - 数据库操作尽量封装为接口，这样才能在测试中 mock 掉。
- 不要怕写 helper 函数或 mock 类型，它们能让你的测试更干净、更专注。
基本上就这些。写测试不是为了覆盖率好看，而是为了让代码改得安心、上线不慌。依赖注入和 mock 是支撑这一切的基础。
