Golang数据库Mock测试技巧与实战

本文深入剖析了Go语言中数据库Mock测试的核心陷阱与最佳实践，重点揭示了为何不能直接将sqlmock.Mock接口对接*sql.DB、如何正确使用sqlmock.New()创建可注入的mock实例并严格校验错误和期望达成，详解了占位符（?、$1）在不同驱动下的精准正则匹配技巧，直击Scan结构体时“wrong number of columns”的常见根源——列名顺序、数量、类型及NULL处理的严苛一致性要求，并理性指出sqlmock的边界：当面对复杂SQL、数据库特有语法或需模拟真实状态机行为（如并发锁、事务隔离、连接池超时）时，应果断转向sqlite内存库或testcontainers等更贴近生产环境的替代方案。

为什么不能直接用 sqlmock.Mock 对接 *sql.DB

因为 sqlmock.Mock 本身不是 *sql.DB，它只提供一个模拟的 sqlmock.Sqlmock 接口实例，必须通过 sqlmock.New() 创建，并且要手动把 mock 的 *sql.DB 注入到你的业务代码中。常见错误是试图对已有真实 *sql.DB 调用 Mock 方法——这会 panic，因为真实 DB 没有 Mock 字段。

正确做法是：在测试中用 sqlmock.New() 得到一对 *sql.DB 和 sqlmock.Sqlmock，再把前者传给被测函数（比如通过构造函数、参数或依赖注入容器）。

• 务必检查 db, mock, err := sqlmock.New() 的 err，忽略它会导致后续 ExpectXXX 失效却无提示
• 测试末尾必须调用 mock.ExpectationsWereMet()，否则未执行的 expect 不报错，容易漏覆盖
• 如果业务层用的是 *gorm.DB，不要对 *sql.DB 做 expect —— GORM v2 默认用 session 封装，SQL 可能被重写或拆分，应改用 gorm.io/gorm/migrator 或更稳妥的 gormtest 方案

如何让 sqlmock 正确匹配带占位符的查询语句

sqlmock 默认使用正则匹配 SQL，而 Go 的 database/sql 驱动（如 mysql 或 postgres）会把 ? 或 $1 替换为具体值再发给数据库。但 sqlmock.ExpectQuery() 期望你传入原始 SQL 模板，不是插值后的字符串。

例如业务代码执行：db.Query("SELECT name FROM users WHERE id = ?", userID)，测试里应写：mock.ExpectQuery("SELECT name FROM users WHERE id = \\\\?").WithArgs(123)（注意 \\? 是转义后的字面量问号）。

• PostgreSQL 驱动用 $1 占位符，expect 时写 "\$1"（双引号内需反斜杠转义）
• MySQL 驱动用 ?，expect 中写 "\\?"；SQLite 同理
• 避免用 ExpectQuery(".*users.*") 这类模糊正则——它可能误匹配其他语句，导致测试脆弱
• 若 SQL 中有换行或空格差异，用 regexp.QuoteMeta() 包裹原始语句再拼接，确保字面量精确匹配

Mock 扫描结构体时为何 Scan() 总返回 “wrong number of columns”

这是最常踩的坑：调用 rows := mock.NewRows([]string{"id", "name"}) 后，必须用 rows.AddRow(1, "alice") 提供与列名数量、类型严格一致的数据行。如果结构体字段数（比如 type User struct { ID int; Name string }）和 AddRow() 传参个数不等，rows.Scan(&u) 就会报这个错。

更隐蔽的情况是字段类型不匹配：比如 DB 列是 INT，但 AddRow("1", "alice") 传了字符串，Scan() 无法自动转换，也会失败。

• 列名顺序必须和 SELECT 字段顺序完全一致，不能只看字段名
• 用 sql.NullString、sql.NullInt64 等类型接收可能为 NULL 的列，对应 AddRow(sql.NullString{String: "x", Valid: true})
• 如果结构体嵌套或用了 sql.Scanner 自定义类型，mock 行数据必须满足其 Scan() 方法签名，否则 panic

替代方案：什么时候该放弃 sqlmock，改用内存数据库

当你的 SQL 包含复杂 JOIN、子查询、窗口函数，或依赖数据库特有行为（如 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE），sqlmock 的正则匹配和静态响应就力不从心了。此时可切到轻量级内存数据库，比如 sqlite（用 :memory: DSN）或 pgxpool + testcontainers-go 启一个临时 PostgreSQL 容器。

sqlite 示例：sql.Open("sqlite3", ":memory:")，然后用真实 CREATE TABLE 和 INSERT 初始化 schema 和测试数据，业务代码完全不用改。

• sqlite 不支持某些 PostgreSQL/MySQL 语法（如 RETURNING），选型前先确认兼容性
• testcontainers 启停慢、依赖 Docker，适合集成测试而非单元测试
• 如果只是想绕过网络 I/O，但又需要事务隔离，可用 github.com/mattn/go-sqlite3 的 _ "github.com/mattn/go-sqlite3" + :memory:，启动快且零外部依赖

真正难 mock 的从来不是 SQL 本身，而是数据库状态机行为：比如并发事务下的锁等待、死锁检测、连接池耗尽时的 timeout。这些只有真实驱动+内存库才能逼近。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang数据库Mock测试技巧与实战》文章吧，也可关注golang学习网公众号了解相关技术文章。