Golang中的网络接口Mock方案 Go语言httptest包测试Web服务

httptest.newserver 适合测 http 客户端而非服务端，它启动独立 tcp 服务并返回硬编码响应，绕过真实路由与中间件；测服务端 handler 应用 httptest.newrecorder，其纯内存模拟 responsewriter，可精确捕获状态码与响应体。

httptest.NewServer 适合测 HTTP 客户端，不是服务端

很多人一看到 httptest 就默认用来“Mock 自己的 Web 服务”，结果跑起来发现路由没生效、中间件不触发、甚至 http.ServeMux 根本没被调用——因为 httptest.NewServer 启的是一个**独立进程级 HTTP 服务**，它只接收请求并返回你硬编码的响应，完全绕过你的实际 handler 和路由逻辑。

真正该用它的场景是：你在写一个 HTTP 客户端（比如调第三方 API 的封装），需要一个可控的远端地址来验证请求构造、重试、超时等行为。

• 用 httptest.NewServer 时，你得自己写 http.HandlerFunc 模拟响应，和你的业务代码零耦合
• 它启动的是真实 TCP 端口，会占用资源，测试完必须调 srv.Close()，否则可能端口冲突
• 不支持 https，默认走 HTTP；要测 TLS 行为得换 httptest.NewUnstartedServer + 手动配置 tls.Config

httptest.NewRecorder 是测服务端 handler 的正确起点

想验证自己的 http.HandlerFunc 或 gin/echo 路由是否按预期处理请求、写入状态码和 body，httptest.NewRecorder 才是直连核心。它不启网络，纯内存模拟 ResponseWriter，能精确捕获你 handler 里调 w.WriteHeader()、w.Write() 的所有输出。

典型误用是拿它去“测整个 HTTP 服务启动流程”，比如在测试里跑 http.ListenAndServe ——这既慢又难控制端口，还掩盖了 handler 本身的问题。

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

• 传给 handler 的 *http.Request 必须用 http.NewRequest 构造，注意 method、URL、body 都得显式设好
• req.Header.Set("Content-Type", "application/json") 这类头设置不能漏，尤其测 JSON 解析时
• 如果 handler 依赖 context（如超时、trace ID），记得用 req = req.WithContext(...) 注入
• 别直接断言 rec.Body.String()，先检查 rec.Code 是否为 200，再看 body 内容

第三方库 httprouter / Gin / Echo 的 Mock 要绕开框架启动逻辑

框架自带的测试辅助（如 Gin 的 gin.CreateTestContext、Echo 的 echo.New().NewContext）本质还是包装了 httptest.NewRecorder，但它们对中间件、路由匹配、绑定解析的支持程度差异很大。直接用原生 http.ServeMux + NewRecorder 反而更可控、更轻量。

例如用 Gin 时，如果你只测某个 handler 函数，没必要启动整个 gin.Engine：把 handler 提成包级函数，传入 http.ResponseWriter 和 *http.Request 即可单元测；只有涉及路由参数解析、中间件链路时，才用框架的测试上下文。

• Gin 的 c.ShouldBindJSON(&v) 在测试中可能 panic，因为默认 Content-Type 是空的，得手动设 req.Header.Set("Content-Type", "application/json")
• httprouter 不支持直接 mock 路由树，得用 router.ServeHTTP(rec, req)，且需确保注册路径和测试请求路径完全一致（包括末尾斜杠）
• Echo 的 echo.New().Router().Add() 可以预注册路由，但测试时仍要调 router.ServeHTTP()，别忘了 echo.New().NewContext(req, rec) 创建上下文

Mock 外部依赖（DB、redis、第三方 API）别塞进 HTTP 测试里

HTTP handler 测试里混着 db.QueryRow 或 redis.Client.Get，等于把单元测试写成了集成测试：速度慢、不稳定、失败原因难定位。真正的 Mock 应发生在 handler 依赖的 service 层，而不是 HTTP 层。

比如 handler 调用了 userSvc.GetUserByID(ctx, id)，那就 mock 这个 userSvc 接口，而不是在测试里起个 fake Redis 实例或往 test DB 插数据。

• 用 interface 定义 service（如 type UserService Interface { GetUserByID(context.Context, int) (*User, Error) }），handler 只依赖 interface
• 测试时传入 Struct 实现该 interface，方法体直接 return 预设值或 error
• 避免用 monkey.Patch 等运行时打桩，它破坏类型安全，且在 go test -race 下可能出问题
• 如果非要用真实依赖（如测 OAuth callback endpoint），至少用 httptest.NewServer 模拟那个第三方服务，别连真环境

最常被跳过的一步：handler 里用了 log.printf 或 zap.L().Info，但测试没重定向日志输出，导致失败时看不到关键调试信息。用 log.SetOutput(ioutil.Discard) 或 zap 的 ztest.NewLogger(t) 控制它。