buffalo test 默认不运行 Go 测试文件，仅执行内置 HTTP 集成测试（如 actions/actions_test.go 中的 TestApp），忽略所有 xxx_test.go 单元测试；需用 go test 运行原生测试。
buffalo test 命令默认不运行 Go 测试文件
Buffalo 的 buffalo test 命令不是简单地调用 go test，而是启动一个完整的测试生命周期：编译二进制、启动应用、运行内置的 HTTP 集成测试（基于 BuffaloTest）。它**完全忽略你写的 xxx_test.go 文件**，除非你显式配置。
常见错误现象：buffalo test 运行后“没报错但也没执行你的 TestXXX 函数”，或者提示 no tests to run —— 这是因为它压根没扫描你的测试文件。
- Buffalo 默认只识别并运行
actions/actions_test.go中符合其测试框架约定的函数（如func TestApp(t *testing.T)） - 自定义的单元测试（比如
models/user_test.go或actions/users_test.go中的普通TestCreateUser）不会被触发 - 想跑纯 Go 单元测试，必须绕过
buffalo test，直接用go test
在 Buffalo 项目中正确运行 Go 原生测试
直接使用 go test 是最可靠的方式，但要注意路径和构建标签。
Buffalo框架 1.0.1
下载
Buffalo框架 1.0.1 版本源码包下载，适合需要错误处理改进、依赖更新、render.Download 注释和 request logger 调整的 v1 项目。
- 在项目根目录下运行
go test ./actions/...可递归运行所有 actions 下的测试 - 若测试依赖 Buffalo 的环境（如数据库连接、App 初始化），需先确保
app.go被 import，且测试中手动调用app.New()或复用actions.App() - 避免在测试里用
buffalo dev或buffalo test启动的全局状态 —— 它们是隔离的进程，不影响go test的执行环境 - 如果测试文件里用了
//go:build !development这类构建标签，记得加-tags参数，例如：go test -tags=sqlite ./models
混合使用 buffalo test 和 go test 的典型场景
HTTP 集成测试和逻辑单元测试本就该分层运行，Buffalo 并不反对你同时用两种命令。
-
buffalo test：验证路由是否注册、中间件是否生效、HTML 渲染是否正常、JSON 返回结构是否符合预期 -
go test ./models -v：验证 GORM 模型钩子、自定义验证方法、数据库迁移逻辑 - CI 脚本中建议分两步：
buffalo test+go test ./... -short，后者加-short可跳过耗时的集成测试（需你在测试中用if testing.Short() { t.Skip() }判断） - 注意
buffalo test会自动设置BUFFALO_ENV=test，而go test不会 —— 如果你的测试依赖环境变量，得自己os.Setenv("BUFFALO_ENV", "test")
容易被忽略的测试初始化陷阱
Buffalo 的 actions.App() 在首次调用时会缓存 App 实例，但这个实例默认不加载数据库或中间件 —— 很多测试失败其实卡在这里。
- 别在测试里直接用
actions.App()发起 HTTP 请求，它返回的是未启动的 App；要用buffalo.Test包提供的buffalo.Test实例，例如：buffalo.Test(app, "GET", "/users") - 模型测试中若用
pop.Connection，确保pop.Connect("test")已调用，且database.yml中test环境配置正确（特别是 SQLite 路径是否带:memory:） - 修改了
app.go中的中间件顺序？buffalo test会按新顺序执行，但go test中手动构造的请求可能绕过中间件 —— 这不是 bug，是设计差异
真正麻烦的从来不是命令敲不对，而是以为 buffalo test 和 go test 在做同一件事。它们面向不同层级，混用前得先分清你要测的是“请求能不能通”，还是“函数返回对不对”。
