根本原因是未调用 runspecs：ginkgo 不依赖 go test 自动发现，必须在 func testxxx(t *testing.t) 中先 registerfailhandler(fail)，再唯一调用 runspecs(t, "suite")，否则 describe/it 不注册、不执行，导致 panic 或“no tests to run”。
为什么Ginkgo测试一跑就panic
根本原因是没调用 RunSpecs。Ginkgo不靠 go test 自动发现测试，它需要显式启动框架。漏掉这步，Describe 和 It 块压根不会执行，看起来像“没跑”，其实是框架根本没起来。
常见现象：go test 输出 ok ./pkg 0.001s，但断言一句没触发；或者直接 panic 报 no tests to run。
- 每个测试文件必须有
func TestXxx(t *testing.T)入口函数 - 该函数里必须先调用
RegisterFailHandler(Fail)，再唯一调用RunSpecs(t, "MySuite Suite") - 别在
init()或包级变量初始化里调用RunSpecs，会破坏go test生命周期 - 如果用
ginkgo run命令，则不用手写TestXxx，但此时不能混用go test
Describe/Context/It 怎么分层才不乱
微服务天然有多层协作（API → Service → Repo），Ginkgo 的树状结构不是为了炫技，而是强制你把逻辑拆开。一个登录流程不该塞进一个 It，而应按职责分层：
-
Describe("UserService")覆盖整个服务契约 -
Context("when password is correct")表达前置条件分支 -
It("returns user and no error")只验证单一输出行为
错误做法：用 t.Run() 模拟分组，但无语义约束，容易让状态泄漏或断言模糊。Ginkgo 强制结构后，BeforeEach 隔离每个 It 的 mock 初始化，你不用再手动重置 DB 或 HTTP client。
注意：所有 Describe 块必须带非空字符串主题（如 "UserService"），不能是变量或空串——否则 ginkgo -focus 匹配失效。
Mock依赖时gomock和BeforeEach怎么配合
微服务单元测试的核心是隔离外部依赖，但直接 new 真实 Repo 会导致测试慢、不稳定、难调试。Ginkgo 本身不提供 Mock，必须搭配 gomock 生成接口桩。
- 先定义接口（如
UserRepo），再用mockgen生成桩类型MockUserRepo - 在
BeforeEach里创建新 mock 实例并注入，确保每个It拥有独立状态 - 别在
BeforeSuite里初始化 mock——那是给 DB 连接池、HTTP server 这类全局资源用的 - 验证时用
mockCtrl.Finish()检查是否所有期望调用都被执行，避免漏断言
典型陷阱：把 mock 对象存在包级变量里，多个 It 共享同一实例，导致断言冲突或状态污染。
Gomega断言失败为啥不显示实际值
因为没注册 Fail 处理器。Gomega 本身不直接输出失败详情，它依赖你传给 RegisterFailHandler 的函数来抛出错误。没注册，或注册了但函数没正确转发 t.Fatal，就会看到空 panic 或 “test timed out” 这类误导信息。
- 必须在
TestXxx函数里、RunSpecs之前调用RegisterFailHandler(Fail) -
Fail来自github.com/onsi/ginkgo/v2，不是标准库的testing.T.Fail - 别写成
RegisterFailHandler(t.Fail)——t在 handler 里不可用，会 panic - 如果用了
ginkgo run，Fail默认已注册；但手动go test时这一步绝不能省
真正容易被忽略的是：Fail 处理器注册位置必须紧挨着 RunSpecs，且不能被条件逻辑包裹——哪怕只差一行，断言失败时也可能看不到具体值对比。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
