Go测试函数必须以Test开头、接收*testing.T参数、命名符合TestXxx规则且文件名为xxx_test.go；t.Error记录错误后继续执行，t.Fatal则立即终止当前测试函数。
Go 的 testing 包本身不支持 setup/teardown 钩子，也不支持参数化测试或子测试的自动分组——这意味着你得手动管理状态、用 t.Run() 显式划分逻辑、靠命名和结构来模拟“测试套件”。
如何写一个最简可运行的测试函数
Go 要求测试函数必须以 Test 开头、接收单个 *testing.T 参数、且放在 _test.go 文件里。文件名和函数名都必须符合约定，否则 go test 直接忽略。
- 文件名必须是
xxx_test.go（不能是test_xxx.go或xxx_test.golang） - 函数签名必须是
func TestXxx(t *testing.T)（Xxx首字母大写，不能带下划线） - 不返回值，不接受额外参数，哪怕只是想传个字符串也会编译失败
示例：
func TestAdd(t *testing.T) {
result := add(2, 3)
if result != 5 {
t.Errorf("expected 5, got %d", result)
}
}
为什么 t.Fatal 和 t.Error 行为差别这么大
t.Error 只记日志并继续执行后续语句；t.Fatal 记日志后立刻终止当前测试函数——但注意，它不会跳出整个测试文件，也不会影响其他测试函数运行。
立即学习“go语言免费学习笔记（深入）”；
- 用
t.Fatal适合检查前置条件，比如配置加载失败、临时目录创建失败 - 用
t.Error更适合校验多个断言，避免漏掉后面几个错误 - 误用
t.Fatal在循环里会导致只测第一个元素就退出，常见于遍历测试用例时
反例（容易踩坑）：
for _, tc := range cases {
if tc.input < 0 {
t.Fatal("input must be non-negative") // 错！会跳过所有后续 tc
}
// ...
}
怎样组织多个场景而不重复写 setup 代码
Go 没有全局 setup，但可以用 t.Run() 嵌套 + 闭包变量来共享初始化逻辑。每个 t.Run 是独立的子测试，失败互不影响，还能在 go test -run=TestName/xxx 中单独运行。
- 把共用的 setup 放在
t.Run外部，但注意变量作用域——别在循环里直接捕获迭代变量 - 子测试名建议用有意义的字符串，比如
"negative_input"而不是"case1" - 如果 setup 成本高（如启动 mock server），考虑用
sync.Once或包级变量缓存，但要小心并发测试间的干扰
正确写法：
func TestCalculate(t *testing.T) {
calc := NewCalculator() // 共享实例
for name, tc := range map[string]struct{
input int
want int
}{
"positive": {2, 4},
"zero": {0, 0},
} {
tc := tc // 必须显式复制，否则闭包会捕获循环变量
t.Run(name, func(t *testing.T) {
got := calc.Square(tc.input)
if got != tc.want {
t.Errorf("Square(%d) = %d, want %d", tc.input, got, tc.want)
}
})
}
}
哪些情况必须加 // +build test 或忽略 vendor
当你在测试中 import 了仅用于测试的包（比如 github.com/stretchr/testify/assert），而主程序不依赖它时，go build 会报错说找不到包——但 go test 默认会处理。真正容易出问题的是交叉编译或 CI 环境中禁用了 test tags 的场景。
- 如果测试文件用了 cgo 或需要特定构建约束，需在文件顶部加
// +build test并空一行 - 某些 CI 工具（如旧版 Drone）默认不启用 test 构建 tag，导致测试文件被跳过
- vendor 目录里如果有测试专用依赖，确保
go test没被-mod=readonly卡住——它可能拒绝读 vendor 下的非主模块包
这不是日常开发高频问题，但在锁定依赖的生产 CI 流程里，一不留神就会出现 “tests pass locally but fail on CI”。
