Go mod 好菜系列 - 0x11 ginkgo/gomega 这口 BDD 测试风味更重

如果说 testify 是“把测试写得更顺手”，那 ginkgo/gomega 更像是在说：“不只是顺手，我们还想让测试更像一段行为描述。”这套风格有人特别喜欢，也有人觉得太花。两边都能理解，关键还是看团队和项目。

它和 testify 最核心的差异是什么

• testify 更像标准库测试的增强工具
• ginkgo/gomega 更像一套测试写作风格

也就是说，前者是在你现有测试结构上加顺手能力，后者则在更大程度上影响你“怎么组织测试描述”。

Ginkgo 的感觉

var _ = Describe("UserService", func() {
    Describe("CreateUser", func() {
        It("should create user when input is valid", func() {
            // test logic
        })
    })
})

这种写法明显比标准库测试更像自然语言结构。你读起来像在看：

• 描述哪个模块
• 描述哪个行为
• 验证应该发生什么

Gomega 的断言风格

Expect(err).To(BeNil())
Expect(user.Name).To(Equal("Raymond"))

它的断言风格也比 testify 更“句子化”。你喜欢不喜欢这件事，非常看个人审美和团队习惯。

为什么有人很喜欢它

• 层次感强
• 复杂行为场景读起来更像说明文
• 适合集成测试和行为驱动测试
• 多人协作时，测试结构更容易按行为拆块

尤其是那种场景比较多、状态转换多、流程链路长的测试，用行为式结构确实会显得更清楚。

但它也真的会显重

如果你的项目测试目前还停留在：

• 几个简单 service 函数
• 一些边界值校验
• 少量接口测试

那 ginkgo/gomega 有时候会显得像“为了组织测试而引入了更重的测试结构”。这不是它不好，而是工具和项目阶段不总是匹配。

它更适合什么

• 复杂集成测试
• 流程和状态驱动明显的测试
• 团队明确喜欢 BDD 风格
• 希望测试更像可读说明文

如果团队本来就更偏直接、务实、标准库派，那 testify 往往已经够了。

小结

ginkgo/gomega 不是“比 testify 更高级”，它更多只是另一种风格：

• 更偏行为描述和结构化测试组织
• 特别适合复杂流程型测试
• 小项目或简单测试里容易显重
• 选它更多是团队测试文化选择，不是单纯功能选择

下一篇我们讲 air。前面的菜都偏库，这道则偏开发体验工具：写服务时自动热重载，到底值不值。