go test 默认不运行包外测试文件，因其仅加载当前目录下以_test.go结尾且package声明与被测包一致的文件；若测试文件包名错误、路径错误或含非法导入，则被静默跳过。
为什么 go test 默认不运行包外测试文件
Go 的测试机制严格按包隔离，go test 只会加载当前目录下以 _test.go 结尾、且 package 声明与被测包一致的文件。如果测试文件写了 package main 或其他包名，它会被完全忽略——连编译都不通过。
常见误操作包括：把测试文件放在错误目录（如根目录而非 pkg/ 下）、测试文件里用了 import "./src" 这类相对路径导入、或者用 IDE 自动生成了错包名。这类问题不会报“找不到测试”，而是静默跳过。
- 确保测试文件和被测代码在同一个目录，且
package xxx一致（比如都是package cache） - 不要在测试文件中 import 当前包的本地路径，如
import "./cache"—— Go 不允许这样导入自身 - 运行时加
-v参数：go test -v，能清楚看到哪些测试函数被发现、执行、跳过
如何用 testmain 控制测试生命周期（比如初始化 DB 连接）
Go 测试默认没有 setup/teardown 钩子，但可通过 func TestMain(m *testing.M) 手动接管整个测试流程。这是做包级共享资源（如临时 SQLite 文件、HTTP server、mock registry）的唯一可靠方式。
关键点在于：必须显式调用 m.Run() 并返回其结果，否则所有测试函数都不会执行，且 go test 会直接退出并报错 exit status 1。
立即学习“go语言免费学习笔记（深入）”；
-
TestMain必须定义在package xxx_test中，且函数签名严格匹配：func TestMain(m *testing.M) - 在
m.Run()前做初始化（如启动 mock server），之后做清理（如关闭 listener、删除临时文件） - 不要在
TestMain里调用t.Fatal等测试断言函数 —— 此时*testing.T不可用 - 若初始化失败，应
os.Exit(1)，而不是 return；否则测试框架认为成功，但实际没跑任何用例
func TestMain(m *testing.M) {
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte("ok"))
}))
defer srv.Close()
os.Setenv("API_BASE", srv.URL)
code := m.Run() // ← 必须有
os.Unsetenv("API_BASE")
os.Exit(code)}
如何安全地模拟依赖（避免修改原包或引入全局状态）
Go 没有反射注入或运行时 stub 能力，所以“模拟”本质是**提前约定接口 + 构造时传入**。最易踩坑的是：把依赖声明在全局变量里（如 var db *sql.DB），导致测试时无法替换，或多个测试并发修改同一变量引发竞态。
正确做法是让被测结构体接收依赖作为字段，并提供可选构造函数：
- 被测类型不持有具体实现，只持有一个接口（如
type Store interface { Get(key string) ([]byte, error) }） - 导出的构造函数接受该接口：
func NewService(s Store) *Service，而非内部 new 出来 - 测试时传入自定义 struct（哪怕只实现一个方法）或
gomock/gomega生成的 mock 对象 - 避免使用
init()初始化全局依赖，它无法在测试中重置
例如，不写 var client = &http.Client{Timeout: 5 * time.Second}，而写：
type Clienter interface {
Do(*http.Request) (*http.Response, error)
}
type Service struct {
httpClient Clienter
}
func NewService(c Clienter) *Service {
return &Service{httpClient: c}
}
为什么 go test ./... 会失败，但 go test 却通过
因为 ./... 递归扫描所有子目录，包括那些含 main 包或未写测试的目录。一旦遇到 package main 的 _test.go，go test 就会尝试编译它为可执行文件，但测试文件不能有 func main()，于是报错 cannot use _test.go as package main。
更隐蔽的情况是：某个子目录下存在 xxx_test.go，但它属于另一个模块（比如 vendor 里的第三方包），而该文件又没加 // +build !test 约束，就会被错误纳入编译范围。
- 检查报错路径，定位到具体哪个
_test.go文件触发失败 - 确认该文件是否真的属于当前项目 —— 很可能是
vendor/或internal/下的误匹配 - 对非本包测试文件加构建约束：
// +build ignore或// +build unit，再配合go test -tags=unit - 日常开发推荐用
go test ./pkg/... ./cmd/...显式指定路径，避开无关目录
包级别测试不是靠“覆盖所有文件”来保证质量，而是靠清晰的边界、可控的依赖注入和明确的生命周期管理。最容易被忽略的，其实是 TestMain 里忘了 os.Exit(code)，或者 mock 接口漏实现了某个边缘方法，导致测试看似通过，实则没走真实路径。
