测试真实世界的 Go 后端并不像很多人想的那样

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您将其翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

对 Go 后端测试套件的观察

我已经审阅了足够多的 Go 后端测试套件，注意到一个模式。拥有最多单元测试的服务往往也是生产事故最多的服务。这并不是因为单元测试导致了事故——而是因为编写单元测试并以此收工的团队没有测试实际会出问题的地方。

常见的生产缺陷

• “上下文截止时间没有传播到后台 goroutine，导致在负载下泄漏。”
• “两个服务在 happy path 上达成一致，但错误形状合约在六个月前已经分歧，现在一个返回 status.Code(codes.Unavailable)，而另一个期望 codes.ResourceExhausted。”
• “重试逻辑存在竞争条件。在测试规模流量下可以工作；在生产环境的 10 倍负载下会双重计费。”
• “数据库迁移在 SQLite（我们的测试 DB）上可以运行，但在 Postgres 15 更严格的规划器上不行。”

没有单元测试能捕获这些问题。另一套测试形状可以捕获。

重新思考测试分类

tl;dr — 停止把测试框定为“单元 vs 集成”。那是隔离层级的维度，而它是最不有趣的。对生产环境的 Go 来说，重要的维度是：

• 确定性行为（受控时钟、带种子随机数）
• 并发正确性（竞争检测器、压力测试）
• 合约忠实度（共享模式、真实下游）
• 环境忠实度（真实数据库、真实网络）

围绕这些设计你的测试套件；覆盖率自然随之提升。

“Unit tests test one function. Integration tests test several. E2E tests test the whole system.”
那种框定是初级工程师的起点。当你在调试生产中 Go 服务为何悄然丢失消息时，它就不再有用。隔离层级不是有趣的维度。真正重要的是：

重要的维度

• 确定性 vs 非确定性行为。 相同的输入每次都会产生相同的输出吗？
• 并发正确性。 竞争条件是否仍然被捕获？
• 合约忠实度。 你对下游的假设是否与它们的实际行为相匹配？
• 环境忠实度。 你的测试环境是否足够接近生产运行时，以捕获真实的 bug？

一个测试在隔离层级上可能是“单元”，但在上述两三项上得分。也可能是“集成”，却在全部四项上失分。

不稳定的测试

如果你无法将测试运行一千次且得到相同的结果，那么你就有一个不稳定的测试，而不稳定的测试比没有测试更糟——它们会让团队忽视失败。

非确定性的来源

1. 任何调用 time.Now()、time.After()、time.Sleep()，或依赖墙钟时间间隔的测试都是地雷。它在开发者的笔记本电脑上可以正常运行，却会在慢速的 CI 运行器上因垃圾回收（GC）触发而失败。
   修复方法： 注入一个时钟。一个最小的时钟接口：

   type Clock interface {
       Now() time.Time
       Sleep(d time.Duration)
       After(d time.Duration)
   }

2. （原文仅明确列出了第一个来源；其余两个来源是根据顺序声明暗示的。）

Test Taxonomy

• Fast tests（整个文件几秒）：纯函数、算法、小状态机。每次保存时运行。
• Concurrency tests（几秒到一分钟）：所有使用 goroutine 的情况。使用 -race 运行。在 PR 中运行。
• Deterministic integration tests（每个测试个位数秒）：一个模块 + 假实现 + 假时钟。足够快，可纳入主测试运行。
• Real‑infra integration tests（每个测试几秒）：一个模块 + 通过 Testcontainers 使用真实的 DB / Kafka / Redis。PR 中运行，超时时间更长。
• Contract tests（毫秒级）：验证与下游共享的 schema。每次 schema 更改时运行。
• Stress tests（分钟级）：高迭代、高并发，使用 -race。每晚或按计划运行。
• End‑to‑end tests（分钟级）：真实服务、真实网络，对接预发布环境。发布前运行。

你会注意到：“unit”和“integration”并未出现在分类中。这是有意为之。隔离程度是实现细节。测试的目的才是分类依据。

实用测试技巧

• 使用 t.Cleanup 而不是 defer。清理操作按后进先出顺序执行，可以在测试的任何位置添加，并且在测试出现 panic 时更能存活。
• 倾向于使用表驱动测试。将二十个测试作为切片中的行来写，胜过二十个几乎相同的测试函数。
• 对于设置失败，使用 t.Fatalf 而不是 t.Errorf 使测试失败。设置出错应当中止；而断言出错可能会让测试继续收集更多的失败。
• 对复杂输出使用 golden 文件。如果你在验证生成的 SQL 查询、序列化事件或 JSON 响应，golden 文件的比较比长字符串字面量更易读。
• 为慢速测试使用带构建标签的单独 _test.go 文件。//go:build integration 让你可以显式运行这些测试。

覆盖率考虑

覆盖率数字是骗人的。问题不在于“测试执行了多少百分比的代码行”——而在于“有多少百分比的风险行为被测试覆盖，并且当这些行为出错时测试能够真正失败”。

一个拥有 95 % 行覆盖率，却没有竞争条件测试、没有真实数据库测试、且大量使用 mock 的集成测试的代码库是脆弱的。相反，一个只有 60 % 行覆盖率，但在 CI 中使用 go test -race、为数据库使用 Testcontainers，并为每条热点并发路径提供压力测试的代码库则不是如此。

最终建议

我建议的最大转变是：停止从隔离级别的角度思考测试，而是从你真正担心的生产故障模式的角度来思考。将每种故障模式映射到一种测试形态。如果某个故障模式没有对应的测试形态，那么实际上并没有覆盖该故障模式——你只能寄希望它不会发生。

生产对你所期望的有自己的看法。

• Go 的并发关注结构，而非速度 — 使得生产级 Go 成为可能的并发模式。
• 分布式系统中的 Go Context：在生产中真正有效的做法 — 我审查的 Go 服务中最常见的测试缺口。
• 为什么你的“快速失败”策略正在毁掉你的分布式系统 — 一种在生产中出现的故障模式，除非专门为其设计测试，否则很难进行测试。