Go测试中必须用替身替代真实数据库，因其拖慢速度、引入依赖、导致数据污染和随机失败；应通过接口抽象数据库操作，优先使用轻量stub，显式验证错误分支。
Go测试中为什么不能直接连真实数据库
真实数据库会拖慢测试速度、引入环境依赖、导致测试间数据污染，还可能因网络或权限问题让测试随机失败。单元测试的核心是隔离和可控，所以必须用替身（mock/stub）替代 *sql.DB 或 gorm.DB 等实际数据库句柄。
用 interface 抽象数据库操作是前提
Go 的接口天然适合替身设计——只要你的业务代码不直接依赖 database/sql 或 ORM 实例，而是依赖自定义接口，就能在测试时注入模拟实现。比如：
type UserRepository interface {
Create(*User) error
FindByID(int) (*User, error)
Update(*User) error
}
如果业务函数签名是 func HandleUser(db *sql.DB, id int)，那就没法干净替换；必须改成 func HandleUser(repo UserRepository, id int)。
- 所有数据库交互方法都收进接口，哪怕只有一两个方法也要抽
- 避免在接口里暴露底层类型（如
Exec、QueryRow），否则 mock 会绑定具体 driver - 接口命名以功能为主（
UserRepository），而非技术为主（SQLUserRepo）
三种常用替身方式对比：mock / stub / in-memory DB
mock（如 gomock）适合验证调用顺序和参数，但易过度耦合实现细节；stub（手动实现接口）轻量、稳定，适合多数场景；in-memory DB（如 sqlite://:memory: 或 entgo/dbtest）能测 SQL 逻辑，但仍是真实驱动，不算纯单元测试。
- 优先写一个简单的
StubUserRepository结构体，实现UserRepository接口，内部用 map 存数据 - 需要验证「是否调用了
Create」或「传入的User.Name是否为 "test"」时，才上gomock - 用
sqlite做集成测试可以，但别把它当单元测试跑——它启动慢、不保证并发安全、且无法覆盖连接超时等错误分支
测试中容易漏掉的错误路径
替身最大的风险是「太顺滑」——mock 总返回 nil 错误，结果线上一连不上数据库就 panic。务必显式构造并验证错误分支：
func TestUserCreate_FailsOnDBError(t *testing.T) {
repo := &StubUserRepository{
CreateFunc: func(u *User) error {
return errors.New("connection refused")
},
}
svc := NewUserService(repo)
err := svc.CreateUser(&User{Name: "alice"})
if !strings.Contains(err.Error(), "connection refused") {
t.Fatal("expected connection error")
}
}
- 每个公开方法都要测至少一个错误返回路径，尤其是
error不为 nil 的情况 - 不要在 stub 中用
panic模拟错误——它绕过 error flow，掩盖真正的错误处理缺陷 - 如果业务里有重试逻辑，stub 需支持「前 N 次失败，第 N+1 次成功」的可配置行为
替身不是越智能越好，而是越贴近你真正要验证的行为越好。写完一个 stub，先问自己：这个测试失败时，是不是真的意味着业务逻辑出错了？
