ginkgo的自描述测试依赖命名规范、describe/context嵌套结构和it的自然语言表达，而非框架特性；describe应对应业务实体或核心行为，context仅表达可断言的前置状态，it须含主语、动作、可观测结果。

Ginkgo 本身不提供“自描述”能力，所谓自描述测试，本质是靠命名规范 + Describe/Context 的嵌套结构 + It 的自然语言表达共同实现的——它不是框架特性，而是写法纪律。

为什么 Describe 和 Context 不能随便嵌套

很多人以为多套一层 Context 就更“清晰”，结果跑 ginkgo -v 时看到测试路径像俄罗斯套娃：Account > Transfer > When source has balance > When destination is frozen > It should return ErrDestinationFrozen。这反而掩盖了真正要验证的契约。

• Describe 应该对应一个业务实体或核心行为（如 "Account transfer"），粒度太大（如 "Banking system"）或太小（如 "Validate amount"）都会削弱可读性
• Context 只用于表达明确的前置状态，且必须可被断言（例如 "When source account is overdrawn" 是有效的，"When user is logged in" 若没在 BeforeSuite 或 BeforeEach 中真实构造登录态，就是假描述
• 嵌套超过两层（Describe > Context > Context > It）大概率说明场景拆分失当，应考虑提取为独立 Describe 块

It 的句子必须能直接转成验收标准

验收测试的“自描述”最终落在 It 上。如果 It 里写的是 "should not panic" 或 "works correctly"，那它就不是验收测试，只是冒烟检查。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 合格的 It 必须包含主语（被测对象）、动作、可观测结果，例如："returns ErrInsufficientBalance when amount exceeds available" —— 这句话去掉 It 前缀，就是 PR 评审时可逐字核对的验收条目
• 避免使用模糊动词：handles、processes、deals with；优先用 returns、creates、rejects、emits 等有明确副作用的动词
• 所有条件必须来自 Context 或 BeforeEach 的显式设定，禁止在 It 体内用 if 模拟状态分支

Ginkgo 不适合写“语言学习测试”

拿 Ginkgo 写 Go 语法练习（比如 “test channel close behavior” 或 “verify defer execution order”）会快速失控：测试名变成教学笔记，It 里塞满 fmt.Println 和注释，断言退化为 Expect(true).To(BeTrue())。

• 语言机制验证更适合用 Go 原生 testing 包 + 单文件 example_test.go（支持 go test -run ExampleXxx 直接执行并校验输出）
• 若坚持用 Ginkgo 练习语言特性，必须满足：每个 It 只验证一个语言点、不依赖外部状态、断言使用 Ω 显式比对值/panic/panicMsg（例如 Ω(func() { close(c) }).Should(Panic())）
• 注意 ginkgo 默认并发执行 It，而某些语言行为（如 runtime.GC() 触发时机）在并发下不可靠，此时需加 Serial 标签或改用 testing

真正的自描述，不靠工具生成文档，而靠每次写 It 时问自己一句：这句话抄到需求文档里，产品敢签字吗？Ginkgo 只是让这个习惯更容易坚持——前提是别把它当语法糖，而当成一种约束。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！