微服务单元测试应围绕接口契约、依赖隔离和状态边界组织：用接口抽象外部依赖，子测试覆盖错误路径与边界条件，采用表格驱动防遗漏，精准mock副作用部分，避免隐式依赖与状态泄漏。
直接上结论：微服务单元测试不是“给每个函数写 TestXXX”，而是围绕接口契约、依赖隔离和状态边界来组织——否则测了也白测，CI 里过不了，重构时全崩。
用 interface + 组合替代全局依赖注入
Go 微服务里最常见的陷阱是把 *sql.DB、*http.Client、time.Now 直接硬编码进业务逻辑。这类代码根本没法可靠测试。
- 把外部依赖抽象成接口，比如定义
DBExecutor接口封装Query/Exec方法，而不是直接传*sql.DB - 结构体字段接收该接口，而非具体实现；测试时传入内存 mock（如
mockDB）或sqlmock实例 - 时间依赖用
clock func() time.Time字段代替调用time.Now()，测试中固定返回time.Date(2023, 1, 1, 0, 0, 0, 0, time.UTC) - 不要为了测试加导出字段或暴露内部状态——设计本身就要支持可替换，而不是“打补丁”
子测试（t.Run）必须覆盖错误路径与边界条件
微服务的可靠性取决于它怎么处理异常，但多数人只测 happy path。一个 HandlePayment 函数，不测金额为负、用户不存在、余额不足、幂等 key 冲突，等于没测。
- 每个核心 handler 或 service 方法，至少拆出 3–5 个
t.Run子测试：正常流程、空输入、参数越界、依赖返回 error、超时场景 - 子测试 name 要能直接看出 case 意图，比如
"returns_error_when_amount_less_than_zero"，别用"case1" - 对 error 判断别只用
if err != nil，要检查具体类型或 message，比如errors.Is(err, ErrInsufficientBalance) - 避免在测试里动态构造 expected error message，容易随日志格式变更而误报
表格驱动测试（table-driven）不是炫技，是防漏的关键
微服务里大量逻辑靠 switch / if-else 分支驱动（比如不同消息类型路由到不同 handler），手写一堆 t.Run 容易漏 case，表格驱动能一眼看清覆盖全不全。
- 把输入参数、依赖 mock 行为、预期返回值、是否应 panic 封装进 struct 切片
- 循环里统一调用被测函数，用
t.Fatalf中断失败项，避免后续 case 干扰 - 特别注意 nil 指针、空 slice、零值 struct 这类“看似无害实则崩溃”的输入，必须显式列在表里
- 别在循环里做复杂计算生成
want，提前算好或用常量——测试里混业务逻辑，一改全坏
Mock 不等于伪造一切，重点是控制副作用边界
有人一上来就 mock 整个数据库、HTTP client、Kafka producer，结果测试跑得慢、假阳性高、维护成本爆炸。真正要 mock 的，只是那些会触发网络、磁盘、时钟、随机数等不可控副作用的部分。
- 用
httptest.Server替代真实 HTTP 调用，比 mockhttp.Client更真实且轻量 - 对 Kafka/RabbitMQ，mock consumer/producer 接口即可，不用起真实 broker；但要注意 offset 提交、rebalance 等协议细节是否被忽略
- 避免 mock 日志、metrics、trace —— 它们不该影响业务逻辑正确性；真要验证，用
testify/assert检查是否调用，而非 mock 全部行为 - 第三方库（如
go-micro的 registry、broker）优先用其自带的内存实现（registry/memory、broker/memory），比手写 mock 更贴近真实行为
最难的从来不是“怎么写测试”，而是判断“这个逻辑到底有没有状态泄漏、有没有隐式依赖、有没有跨 goroutine 竞态”。微服务里一个函数看着纯，可能悄悄读了全局 config、改了 shared cache、发了 background goroutine——这些不显式隔离，测得再密也没用。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
