revel框架不内置mock工具，但testsuite结构支持依赖替换；client替换须在before()前完成，推荐用httptest.server模拟外部http依赖，离线测试需禁用app自动初始化。
Revel 框架本身不内置 Mock 工具，但它的 TestSuite 结构天然支持依赖替换——关键不是“怎么 mock”，而是“在哪 mock、mock 什么、怎么验证行为”。
revel.TestSuite 的 Client 替换时机必须在 Before() 之前
Revel 的测试套件默认使用 http.DefaultClient，它会真实发起 HTTP 请求。如果你要模拟 Web 模块（比如控制器中调用外部 API 或数据库驱动的 HTTP 客户端），不能等到 Before() 里再换——因为 revel.TestSuite 的初始化发生在 Before() 之前，此时 Client 已被赋值。
- 正确做法：在测试 struct 初始化时直接覆盖
Client字段，或在init()函数中提前设置全局http.DefaultClient（不推荐，影响其他测试） - 更安全的方式：自定义一个嵌入
revel.TestSuite的 struct，并在构造时传入 mock client - 常见错误现象：
t.Get("/")仍发出真实请求，AssertOk()失败且日志显示连接超时或 404 —— 实际是没 mock 成功，而不是路由问题
Mock 外部 HTTP 依赖要用 httptest.Server 而非纯 interface mock
Revel 测试运行时启动的是一个真实（但轻量）的 HTTP server，所以你 mock 的对象通常不是“某个 service 接口”，而是它内部调用的 *http.Client 所访问的远端地址。这时候用 httptest.NewServer 比手写 mock struct 更可靠、更贴近真实行为。
- 场景举例：你的 controller 中有
http.Get("https://api.example.com/status")，你想断言它被调用了且返回 200 - 实操建议：启动一个
httptest.Server，把它的 URL 注入到被测 controller（通过构造函数或 setter），而不是 mockhttp.Client.Do方法 - 参数差异：
httptest.Server返回的是真实可访问的http://127.0.0.1:xxxx地址，避免 DNS 解析失败或 TLS 验证干扰 - 性能影响：每个测试用例启动一个
httptest.Server开销极小，比用gock或httpmock等库更轻量、无副作用
离线测试 Web 模块必须切断 revel.App 的自动初始化链
Revel 应用启动时会加载 conf、初始化插件、挂载模块（如 testrunner），这些过程可能触发真实数据库连接、Redis 初始化、甚至远程配置拉取。若你不加干预，go test 运行时就会 panic 报 “no app found” 或 “failed to connect to redis”。
- 关键动作：在测试文件顶部加
func init() { revel.DevMode = false; revel.RunMode = "test" }，并确保app.Init不被执行 - 不要依赖
revel.TestSuite自动加载应用上下文——它只适用于功能测试（e2e），不适用于“离线单测 controller 逻辑” - 容易踩的坑：在测试中直接 new 一个 controller 并调用其方法，结果 panic 在
revel.BEFORE钩子里，因为revel.App为 nil；正确做法是手动构造 controller 并注入所有依赖（如 mock 的 service、logger、config） - 示例片段：
func TestMyController_GetData(t *testing.T) { // 手动构造，不走 revel 自动注入 svc := &MockDataService{} ctrl := &MyController{DataService: svc} result := ctrl.GetData(&revel.Params{}) assert.Equal(t, "expected", result) }
真正难的不是写 mock，而是判断哪一层该 mock：Web 模块的 controller 层测试，应该 mock service 层，而不是 mock HTTP client；而 service 层测试，才该 mock 数据库或第三方 API。混淆这两层，mock 就会越写越重、越写越假。
