使用Golang测试第三方中间件_以Redis Mock库为例

推荐优先使用miniredis：它实现resp协议子集，支持pipeline、事务、过期、pub/sub，直连原生redis.newclient()，启动时自动分配端口；redis-test仅stub少量命令，不覆盖连接与超时逻辑。

Redis Mock库选哪个：gomock vs miniredis vs redis-test

测试 Redis 交互时，别用 gomock 手动 mock redis.Client 接口——它不模拟协议行为，一调 Get().Result() 就 panic。真实可用的只有两个方向：纯内存 fake server（如 miniredis），或轻量 client stub（如 redis-test）。前者更贴近生产行为，后者启动快但覆盖命令少。

推荐优先用 miniredis：它实现了 RESP 协议子集，支持 pipeline、事务、过期、Pub/Sub，且能直接复用你的原生 redis.NewClient() 初始化逻辑，不用改业务代码。

• miniredis 启动后暴露真实 TCP 端口，redis.NewClient(&redis.Options{Addr: "127.0.0.1:9999"}) 可直连
• redis-test 是 client 层 mock，只 stub 几个常用方法（Get/Set），不处理连接、重试、context 超时等真实路径
• 别自己写 mockRedisClient 实现 redis.Cmdable——漏掉 Process(ctx, cmd) 或错误包装会导致 test pass 但线上 crash

怎么让 miniredis 和你的测试生命周期对齐

常见错误是全局复用一个 miniredis.Runner，导致测试间数据污染或端口冲突。它必须按测试用例粒度启停，且不能依赖 defer（因为并行测试里 defer 执行顺序不可控）。

正确做法是在每个 test 函数开头启动，在 t.Cleanup() 里关闭：

立即学习“go语言免费学习笔记（深入）”；

func TestCacheUser(t *testing.T) { 	s, err := miniredis.Run() 	if err != nil { 		t.Fatal(err) 	} 	defer s.Close() // 错！这里 defer 不保证在 t.Parallel() 后 clean  	t.Cleanup(func() { s.Close() }) // 对  	client := redis.NewClient(&redis.Options{ 		Addr: s.Addr(), // 自动分配空闲端口 	}) 	// ... 测试逻辑 }

• 每次调 miniredis.Run() 都会绑定新端口，无需手动管理端口号
• 如果测试中需要预置数据，用 s.Set("key", "val") 直接操作内存 store，比发 client 命令更快更稳
• 并发测试（t.Parallel()）下，s.Close() 必须在 t.Cleanup()，否则可能关错实例

Mock 时绕不开的 context 超时和重试逻辑

真实 Redis client 默认带 5s 超时和重试，而 miniredis 响应极快，容易掩盖你代码里没正确传递 context.Context 的问题。比如写成 client.Get(ctx, "k").Result() 没检查 Error，测试永远不报超时，但线上网络抖动就挂。

必须主动触发超时路径来验证健壮性：

• 用 context.WithTimeout(context.background(), time.Microsecond) 构造必超时 ctx，确认你的 handler 能返回 context.DeadlineExceeded
• 不要依赖 miniredis 模拟网络延迟——它不提供延迟控制；真要测重试，得用 redis.FailoverOptions + 多节点 mock，成本高，一般单元测试里跳过
• 如果业务用了 redis.WithContext() 包装 client，mock 时也得保持同构，否则 context 传递链断裂

为什么 DEL、EXPIRE 在 mock 里行为和线上不一致

miniredis 的过期逻辑是惰性删除：只有在 get/set/exists 等访问 key 时才检查 TTL。这意味着 DEL 后立刻 EXISTS 返回 false，但 KEYS * 还能看到已过期 key——这和 Redis 服务端行为一致，但很多人误以为 “过期=立即消失”。

测试里若依赖 KEYS 或 SCAN 列表断言，大概率失败。正确姿势是：

• 避免在测试中用 KEYS —— 它在生产环境禁用，测试也不该依赖
• 验证过期行为，用 GET + time.Sleep(ttl + 10ms) + 再 GET，而不是查 key 是否还在 KEYS 结果里
• miniredis 不支持 CONFIG SET，所以没法开 lazyfree-lazy-expire，但普通场景够用

最麻烦的其实是 lua 脚本——miniredis 支持有限，EVAL 里用 redis.call("EXPIRE",...) 会 panic。真要用脚本，要么切到集成测试跑真 Redis，要么把脚本逻辑拆出单独函数单元测试。