17370845950

Go测试中用内存数据库替代真实DB因启动快、易重置、无并发冲突；正确使用SQLite :memory:需复用同一*sql.DB实例并显式建表；sqlmock适用于纯SQL逻辑验证；Ent内存模式实为SQLite封装，需用enttest.NewMemoryClient并传schema。

Go测试中为什么用内存数据库代替真实DB

因为真实数据库启动慢、状态难重置、并发测试易冲突。内存数据库（如 sqlite 的 :memory: 模式、go-sqlmock、或 ent 的内存驱动）能秒级初始化，事务隔离干净，且不依赖外部服务。但要注意：它只模拟行为，不保证 SQL 兼容性——比如 PostgreSQL 特有函数在 SQLite 里根本不存在。

SQLite :memory: 在 Go test 中的正确打开方式

直接用 sql.Open("sqlite3", ":memory:") 是常见错误：它创建的是单连接内存 DB，每次 sql.Open 都是全新实例，无法跨 goroutine 共享 schema。正确做法是显式执行 CREATE TABLE 并复用同一 *sql.DB 实例。

• 测试前用 db, _ := sql.Open("sqlite3", ":memory:") 初始化一次
• 立即执行建表语句（如 db.Exec("CREATE TABLE users(id INTEGER PRIMARY KEY, name TEXT)")）
• 把 db 传给被测函数或封装进 test helper 结构体
• 避免在每个 test case 里重新 Open —— 否则表结构丢失，报 no such table

func TestUserCreate(t *testing.T) {
	db, _ := sql.Open("sqlite3", ":memory:")
	_, _ = db.Exec("CREATE TABLE users(id INTEGER PRIMARY KEY, name TEXT)")

	repo := &UserRepo{db: db}
	err := repo.Create("alice")
	if err != nil {
		t.Fatal(err)
	}
}

用 sqlmock 拦截 SQL 调用做纯逻辑验证

当你只想验证 DAO 层是否生成了正确的 SQL、参数是否绑定正确，而完全不想碰数据库时，sqlmock 是更轻量的选择。它不执行 SQL，只校验语句模板和参数顺序，适合单元测试而非集成测试。

• 必须调用 mock.ExpectQuery() 或 mock.ExpectExec() 预设期望，否则测试会 panic
• mock.ExpectQuery("SELECT.*").WithArgs(123) 中正则需覆盖完整 SQL（空格、换行都算），建议用 regexp.QuoteMeta 转义字面量
• 测试末尾要调用 mock.As

  

  sertExpectations(t)，否则即使没匹配上也不会失败
• 不支持复杂驱动特性（如 pgx 的自定义类型、MySQL 的 multi-statement）

Ent 框架下启用内存模式的坑

Ent 自带 ent.Driver 接口，官方文档说 “支持内存驱动”，但实际只有 enttest 包提供 enttest.NewMemoryClient() —— 它底层仍是 SQLite :memory:，不是纯内存结构。如果你误以为它是无 SQL 的 mock，就会在写复杂查询时遇到 unsupported operation 错误。

• 必须用 enttest.NewMemoryClient(t, &ent.Schema{Edges: ...}) 显式传入 schema，否则 edge 关系不生效
• 不能混用 ent.Client 和原生 *sql.DB：前者会自动管理事务，后者需手动 BeginTx
• 内存 client 不支持 ent.Migrate 的 WithForeignKeys 等高级选项，foreign key 约束默认关闭

真正难处理的是跨事务一致性：内存 DB 在 test 中看似“干净”，但一旦用了 defer db.Close() 或复用 connection pool，就可能因 GC 时机导致表被意外清空。最稳的方式是每个 test 函数独立 setup + teardown，哪怕多几行代码。