Revel测试套件必须显式启用testrunner模块并配置路由，否则HTTP测试静默跳过；Mock需通过内存DB、TEST模式分支或Service注入实现；JSON断言应使用testify+json.Unmarshal；对接外部Mock服务时须弃用t.Get()改用原生http.Client。
Revel测试套件必须启用testrunner模块
不配置module.testrunner，revel.TestSuite相关方法（如Get()、AssertOk()）根本不会生效——它不是默认加载的模块。你写的测试会静默跳过HTTP请求，只跑空逻辑。
必须在conf/app.conf中显式开启：
module.testrunner = github.com/revel/revel/modules/testrunner
同时确保routes文件里导入了testrunner路由（通常由revel.LoadAppRoutes()自动处理，但自定义路由时容易漏掉）。没这一步，t.Get("/")只是个无副作用的函数调用。
Mock行为要靠测试环境隔离+手动构造响应
Revel原生不提供类似WireMock或pytest-httpserver那样的动态Mock服务。它的TestSuite本质是“启动真实应用+发真实HTTP请求”，所以Mock得换思路：
- 用
Before()切换数据库连接到内存DB（如SQLite in-memory）或清空测试集合，避免脏数据干扰 - 在Controller里加条件分支：检查
revel.BEFORE_ACTION阶段是否处于TEST模式，然后绕过真实外部调用，直接返回预设JSON - 或者更干净的做法：把第三方调用封装进独立Service，测试时用
revel.AppInit()注入Mock实现（比如替换PaymentService为&MockPaymentService{}）
硬编码if revel.RunMode == "TEST"不是好习惯，但Revel生态缺乏标准依赖注入容器，这是现实妥协点。
断言JSON响应别用字符串匹配
Revel的AssertContentType()和AssertOk()只能验状态码和Header，对JSON Body无能为力。直接strings.Contains(string(t.ResponseBody), "error")既脆弱又难维护。
推荐立刻引入github.com/stretchr/testify/assert，配合json.Unmarshal做结构化断言：
var resp map[string]interface{}
assert.NoError(t.T, json.Unmarshal(t.ResponseBody, &resp))
assert.Equal(t.T, float64(400), resp["code"])
assert.Contains(t.T, resp["message"].(string), "invalid token")
注意resp["code"]是float64——Go的json.Unmarshal默认把数字转成float64，不是int，这里容易panic。
分布式Mock服务同步等待需绕过Revel内置HTTP Client
Revel的t.Get()是阻塞同步调用，无法监听“异常载荷流”。如果你对接的是外部Mock服务（比如WireMock集群），且需要精准捕获429 Too Many Requests带Retry-After头的响应，就得弃用TestSuite封装，改用原生http.Client：
- 在
Before()里初始化自定义http.Client，设置Timeout和Transport - 用
client.Do(req)发请求，再手动检查resp.StatusCode和resp.Header.Get("Retry-After") - 别依赖
t.AssertOk()——它只认200，4xx/5xx直接fail测试，你连看Header的机会都没有
Revel的测试抽象层在这里成了障碍，该裸写HTTP逻辑时就得裸写。框架的便利性有边界，跨过边界还硬套，只会让断言逻辑散落在if嵌套里。
