buffalo g test 仅生成空的 actions/_test.go 文件及占位函数（如 HomeHandlerTest），不生成可直接运行的测试代码，也不自动 mock DB、构造请求或添加断言，本质是提供命名规范和文件位置的轻量脚手架。
buffalo g test 生成的是什么
buffalo g test 不生成可直接运行的测试用例，它只创建一个空的 actions/<name>_test.go</name> 文件和占位函数，比如 HomeHandlerTest，里面连 t.Run 都不带——本质是给你留个命名规范+文件位置，其余全靠手写。
它不自动 mock DB、不注入 context、不构造 request/response，也不帮你 assert 返回状态或 JSON 字段。Buffalo 认为“测试逻辑太业务相关”，所以只做最轻量的 scaffolding。
为什么 buffalo test 命令常失败，而 go test 能过
常见现象：buffalo test 报错 failed to load app: failed to initialize database 或卡在 pop.NewConnection；但直接跑 go test ./actions/... 却能通过。
-
buffalo test会完整启动 app 初始化链：加载app.go→ 连 DB → 初始化 middleware → 调用所有init()函数 -
go test只编译并运行你指定包下的测试函数，完全绕过 Buffalo 的启动流程 - CI 中应禁用
buffalo test，改用分层go test：单元测试（无依赖）、集成测试（DB mock）、e2e（真实 DB）分开执行
怎么让生成的 test 文件真正可用
手动补三样东西，才能让 actions/home_test.go 跑起来：
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 导入
"github.com/gobuffalo/buffalo/testutils"—— 提供testutils.NewBuffaloTest快速构造测试用buffalo.Context - 在测试函数里调用
tu := testutils.NewBuffaloTest(t)，再用tu.HTML("/").Get("/")发起请求 - 若涉及 DB，显式跳过 Pop 初始化：在
init()或测试 setup 中设pop.SkipMigrationLock = true，并用tu.DB().TruncateAll()清库
别依赖 buffalo g test 自动生成断言逻辑——它连 assert.Equal 都不加，得自己补。
容易被忽略的初始化陷阱
生成的测试文件默认不处理 plugins.go 和 app.go 中的副作用。比如：
- 如果
plugins.go里有go func() { ... }()启动后台 goroutine，测试进程不会等它结束就退出，导致 flaky test -
app.Use(middleware.Compress{})在测试中仍会尝试压缩响应，但测试用的ResponseWriter没实现WriteHeader，直接 panic - 未设置
BUFFALO_ENV=test时，app.go可能按 development 加载 webpack 中间件，测试报packr: not found
真正稳定的测试起点，不是 buffalo g test，而是删掉生成文件，从 go test -run TestHomeHandler + 手动构造最小 context 开始。
