Beego单元测试不能直接new Controller，因其依赖框架注入的Ctx、Data等字段及Prepare/Finish钩子，否则调用方法会panic；应通过httptest+BeeApp.Handlers进行HTTP层测试，或手动补全上下文。
Beego 单元测试中为什么不能直接 new Controller？
因为 beego.Controller 不是普通结构体，它依赖框架注入的 Ctx、Data、TplName 等字段，以及 Prepare() / Finish() 等生命周期钩子。直接 new(MyController){} 后调用 Get() 会 panic：常见错误是 nil pointer dereference，根源在未初始化 Ctx 或 Data。
真实场景里，这种“直调”只应在测试辅助函数或后台任务中出现，且必须手动补全上下文。否则应走 HTTP 层集成测试路径。
Mock 外部依赖（如数据库、HTTP 客户端）的正确姿势
Beego 项目中，业务逻辑常耦合 models 层或第三方 SDK（如短信、支付）。单元测试时，这些不该被真实调用——它们慢、不稳定、有副作用。
- 用接口抽象依赖：比如定义
type SMSProvider interface { Send(phone, msg string) error }，而非直接调用twilio.Send() - 测试中传入 mock 实现：可手写 struct 实现该接口，或用
gomock自动生成（需先go install github.com/golang/mock/mockgen@latest） - 避免在
init()或全局变量中初始化依赖：这会让 mock 注入失败；改用构造函数或依赖注入容器（如dig） - 注意 ORM 模式：若用 beego 的
orm，mock 推荐替换整个orm.QuerySeter接口，而不是 mockorm.Read()等具体方法——后者易漏覆盖
HTTP 层测试：用 httptest + BeeApp.Handlers 而非启动真实 server
Beego 的控制器测试本质是验证路由+参数解析+响应生成三者是否协同正常。最可靠方式是复用框架内部 handler 链，跳过网络层。关键不是“怎么 mock”，而是“怎么不 mock 就测到真实行为”。
典型错误包括：
- 忘记调用
beego.TestBeegoInit("github.com/your/app")：导致路由未注册，/login返回 404 - 传错初始化路径：路径不是模块根目录（如
go.mod所在位置），配置加载失败，app.conf中的runmode可能仍是prod - 误用
http.ListenAndServe启动测试 server：既慢又难清理，还可能端口冲突；httptest.NewRecorder()+beego.BeeApp.Handlers.ServeHTTP()才是正解 - 忽略中间件影响：若用了
beego.InsertFilter，需确认TestBeegoInit()是否已加载对应 filter，否则测试通过但线上失败
Ginkgo/Gomega 是 Beego 测试的事实标准，但别滥用 BDD 语法
Describe/Context/It 让测试可读性提升明显，尤其对路由行为描述（如 Describe("POST /api/v1/users", ...)）。但要注意：
- 每个
It必须独立：不能靠前一个It的 side effect（如数据库写入）；状态重置要放在BeforeEach里 -
beego.TestBeegoInit()只需在BeforeSuite执行一次；反复调用会重复初始化日志、ORM，可能引发 panic - 断言优先用
Gomega：比如Expect(w.Code).To(Equal(http.StatusOK))比原生if w.Code != 200更易定位失败原因 - 别为了 BDD 而嵌套过深：三层
Context套一层Describe很难维护；平铺 5 个清晰的Describe比一个“全能测试文件”更可持续
真正容易被忽略的是：Beego 的 TestBeegoInit() 不会自动重置数据库连接池或缓存，如果你在测试中修改了全局配置（如 beego.BConfig.RunMode = "dev"），后续测试可能受污染——建议所有配置变更都限定在单个 It 内，并在 AfterEach 中还原。
