gorm+ginkgo数据库测试最常卡在初始化和生命周期管理：必须显式调用runspecs注册测试树，beforesuite安全初始化db并配置连接池，beforeeach开启事务、aftereach强制回滚，避免数据污染与时间戳干扰断言。
直接上 GORM + Ginkgo 做数据库测试，最常卡住的地方不是写不出断言，而是测试根本没跑起来，或者跑起来了但数据残留、事务不回滚、连接池爆掉——这些问题全集中在初始化和生命周期管理上。
TestXxx 函数里漏掉 RunSpecs 就等于没写测试
Ginkgo 不会自动发现 Describe 和 It，必须靠 RunSpecs 显式注册测试树。漏掉这一步，go test 会安静地输出 ok，但零用例执行。
- 每个测试文件（如
user_test.go）必须且仅有一个func TestUser(t *testing.T) - 该函数内必须先调用
RegisterFailHandler(Fail)，再唯一调用RunSpecs(t, "User Suite") -
Describe和It必须写在这个函数体内，不能放在包级作用域或init()中 - 若用
ginkgo run命令则自动注入，但混用go test时这步绝不能省
BeforeSuite 初始化 DB 连接必须线程安全
集成测试要连真实数据库，BeforeSuite 是放 gorm.Open 的合理位置，但它只执行一次，而 ginkgo -p 默认并行运行所有 It，共享的 *gorm.DB 实例必须能承受并发。
- 不要在
BeforeSuite里赋值可变全局变量（如var DB *gorm.DB），更不要在It中调用DB.Session(...)改写其状态 - 推荐封装为函数返回新实例：
func NewTestDB() *gorm.DB { db, _ := gorm.Open(...) ; return db }，再在BeforeEach中按需获取 - 若坚持全局复用，确保底层
*sql.DB已正确配置连接池：SetMaxOpenConns(20)、SetMaxIdleConns(10) - 记得关闭：在
AfterSuite中调用DB.Close()，否则进程退出前连接不释放
事务回滚不干净导致测试间污染
GORM 集成测试最怕“上一个 It 插了数据，下一个 It 查到了”，根本原因是没统一用事务包裹或没正确回滚。
- 别依赖
DB.Create后手动DELETE清理——容易遗漏、顺序错乱、违反原子性 - 标准做法：在
BeforeEach中开启事务，在AfterEach中强制回滚：var tx *gorm.DB BeforeEach(func() { tx = DB.Begin() }) AfterEach(func() { tx.Rollback() }) - 注意：GORM V2 的
tx是线程安全的，但不能跨It复用；每个It应使用自己的tx实例 - 如果测试中用了原生 SQL 或第三方库直连数据库，事务不会自动捕获它们——这类操作要么禁用，要么显式纳入同一事务上下文
软删除与时间戳字段让断言失效
GORM 默认启用 CreatedAt、UpdatedAt、DeletedAt 字段自动填充，这会让结构体比较断言失败，因为每次创建时间都不同。
- 测试中比对模型时不建议用
reflect.DeepEqual直接比整个 struct，应只比关键业务字段：Expect(user.Name).To(Equal("test")) - 若需验证创建时间，可用
Expect(user.CreatedAt).To(BeTemporally("~", time.Now(), time.Second)) - 软删除场景下，
First默认不查已删记录，测试存在性要用Unscoped().First，否则查不到就 panic - 避免在测试模型里嵌套
gorm.Model—— 它会悄悄带入所有钩子和默认字段，干扰断言逻辑
真正难的不是写出 Describe("User creation") { It("inserts and returns ID") { ... } }，而是每一步初始化都得同时考虑并发安全、资源隔离、时间精度和 ORM 隐式行为——这些地方错一点，测试就从“验证逻辑”退化成“猜随机结果”。
