sqlmock 只拦截 sql.DB 的公开方法,不拦截 sql.Tx,因其是独立类型且方法不经过 mock 的 *sql.DB 实例;事务测试需用 ExpectBegin/ExpectCommit 显式声明生命周期。

为什么 sqlmock 能拦截 *sql.DB 调用但不能拦截 *sql.Tx?
因为 sqlmock 只对 *sql.DB 的公开方法(如 Query、Exec、Prepare)做代理拦截,而 *sql.Tx 是独立类型,其方法调用不经过 sqlmock 注入的 *sql.DB 实例。如果你在事务里直接调用 tx.Query,mock 就不会生效,测试会 panic 或报错 sql: Tx.Query: driver does not support tx.Query。
- 正确做法:用
mock.ExpectQuery()/mock.ExpectExec()等预设期望,并确保所有 DB 操作都走你传入的*sql.DB实例(不是tx) - 若必须测事务逻辑,需手动构造
*sql.Tx并用mock.ExpectBegin()+mock.ExpectCommit()显式声明事务生命周期 - 注意:调用
db.Begin()后返回的*sql.Tx本身不被 mock,但后续对tx.Stmt().Query/Exec的调用仍会回退到 underlying*sql.DB—— 这是 Go 标准库行为,sqlmock无法覆盖
如何写一个能通过 sqlmock 的 INSERT 测试?
关键不是“怎么插”,而是“怎么让 mock 认出你要插哪条语句”。sqlmock 默认严格匹配 SQL 字符串(含空格、换行、参数占位符),所以拼接 SQL 或用 fmt.Sprintf 极易失败。
- 使用
sqlmock.AnyArg()替代具体值,避免因参数格式(如 time.Time 格式、float64 精度)导致匹配失败 - SQL 中统一用
?占位符(MySQL/SQLite 风格),不要混用$1(PostgreSQL 风格),除非你显式配置了sqlmock.WithDSN("postgres://...") - 调用
mock.ExpectExec("INSERT INTO users").WithArgs(...)时,WithArgs的参数顺序必须和db.Exec实际传入顺序完全一致
mock.ExpectExec("INSERT INTO users\\(name, email\\)").WithArgs("alice", "a@example.com").WillReturnResult(sqlmock.NewResult(1, 1))
_, err := db.Exec("INSERT INTO users(name, email) VALUES (?, ?)", "alice", "a@example.com")
if err != nil {
t.Fatal(err)
}
if err := mock.ExpectationsWereMet(); err != nil {
t.Error(err)
}
QueryRow 返回 nil error 但 scan 失败,mock 怎么模拟?
常见错误是只 mock ExpectQuery,却忘了设置返回的 Rows 行为。如果 rows.Scan() 报 sql: no rows in result set,说明 mock 没提供任何数据行;如果报 sql: Scan error on column index 0,说明列数或类型不匹配。
- 用
sqlmock.NewRows([]string{"id", "name"}).AddRow(123, "bob")明确声明列名和一行数据 - 列名必须和你
QueryRow中 SQL 的SELECT字段顺序、大小写完全一致(mock 不做字段映射) - 如果业务代码用
Scan(&id, &name),那么AddRow()的参数类型必须可赋值给对应变量(如int64对应*int,string对应*string)
rows := sqlmock.NewRows([]string{"id", "name"}).AddRow(456, "carol")
mock.ExpectQuery("SELECT id, name FROM users WHERE id = ?").WithArgs(456).WillReturnRows(rows)
var id int
var name string
err := db.QueryRow("SELECT id, name FROM users WHERE id = ?", 456).Scan(&id, &name)
if err != nil {
t.Fatal(err)
}
测试中复用 mock 实例导致 ExpectationsWereMet 失败?
每个 sqlmock.Sqlmock 实例维护自己的期望队列。如果多个测试函数共用同一个 mock(比如定义在包级变量里),前一个测试没清空期望,后一个测试的 ExpectationsWereMet() 就会失败。
立即学习“go语言免费学习笔记(深入)”;
- 每个测试函数内调用
sqlmock.New()创建新 mock 和*sql.DB - 不要在
TestMain或init()里初始化 mock - 如果需要共享 setup 逻辑,封装成函数并返回新
*sql.DB和sqlmock.Sqlmock,由每个测试自己接收和 cleanup - 务必在测试末尾调用
mock.ExpectationsWereMet(),它会检查是否所有Expect*都被触发且无多余调用
最容易被忽略的是:mock 不会自动清理未使用的 Expect —— 比如你写了 ExpectQuery 但实际代码根本没执行那条查询,ExpectationsWereMet 就会报错。这其实是好事,说明测试覆盖不全或逻辑分支没走到。










