Go单元测试需满足：文件名以_test.go结尾、函数名以Test开头、参数为*testing.T且无返回值；测试须与被测代码同包；用t.Fatal/t.Errorf处理错误分支；推荐表驱动测试和接口+fake替换外部依赖。
Go 单元测试从零跑通 go test
Go 的单元测试不需要第三方框架，go test 命令开箱即用。只要文件名以 _test.go 结尾、函数名以 Test 开头、参数为 *testing.T，就能被识别并执行。
常见错误是把测试文件放在错误目录（比如和 main.go 同级但没加 _test.go 后缀），或者函数签名写成 func TestXxx()（漏掉 *testing.T 参数）——这时 go test 会直接跳过，不报错也不运行。
- 测试文件必须和被测代码在同一个包下（同目录、同
package声明） - 测试函数不能有返回值，必须是
func TestXxx(t *testing.T) - 运行全部测试：
go test；只跑某个测试：go test -run TestCalcSum
如何测一个带 error 返回的函数
很多初级项目里，函数会返回 (int, error) 这类组合。测试时不能只校验正常路径，更要覆盖 error != nil 的分支，否则上线后 panic 或静默失败很难排查。
关键点在于：用 t.Fatal 或 t.Errorf 主动中断或记录失败，而不是靠 if err != nil { panic(...) } ——测试中 panic 会导致整个测试提前终止，后续用例无法执行。
func TestDivide(t *testing.T) {
result, err := Divide(10, 0)
if err == nil {
t.Fatal("expected error when dividing by zero")
}
if result != 0 {
t.Errorf("expected 0, got %d", result)
}
result, err = Divide(10, 2)
if err != nil {
t.Fatalf("unexpected error: %v", err)
}
if result != 5 {
t.Errorf("expected 5, got %d", result)
}
}
表驱动测试让多个输入场景一目了然
当一个函数要处理多种边界情况（空字符串、负数、超大值），硬写一堆 TestXxx1/TestXxx2 很难维护。Go 社区惯用「表驱动」方式：用切片定义测试用例，循环执行。
好处是新增 case 只需往表里加一行，逻辑复用，输出也更清晰（失败时能直接看到是哪组输入出问题）。
- 每个
testCase字段名建议语义化（如name,input,expected,shouldErr） - 用
t.Run包一层，让每个子测试独立运行、独立计时、失败时显示具体name - 避免在循环里直接用
range变量地址（闭包陷阱），应显式赋值：tc := tc
func TestParseInt(t *testing.T) {
tests := []struct {
name string
input string
expected int
shouldErr bool
}{
{"empty", "", 0, true},
{"valid", "42", 42, false},
{"negative", "-7", -7, false},
{"invalid", "abc", 0, true},
}
for _, tc := range tests {
tc := tc // 防止 goroutine 闭包捕获循环变量
t.Run(tc.name, func(t *testing.T) {
result, err := ParseInt(tc.input)
if tc.shouldErr {
if err == nil {
t.Fatal("expected error but got nil")
}
return
}
if err != nil {
t.Fatalf("unexpected error: %v", err)
}
if result != tc.expected {
t.Errorf("expected %d, got %d", tc.expected, result)
}
})
}
}
测试依赖外部服务？用接口 + fake 替换
初级项目常直接调用 http.Get、os.ReadFile 或数据库操作，导致测试变慢、不稳定、需要预置环境。正确做法是把依赖抽象成接口，在测试时注入 fake 实现。
例如，一个读配置的函数如果依赖 os.ReadFile，就把它改成接收一个 func(string) ([]byte, error) 类型的读取器，测试时传入闭包即可控制返回内容。
- 不要在测试里启动真实 HTTP server 或连接真实 DB，除非你明确在写集成测试
- fake 实现越简单越好，只模拟必要行为（比如固定返回 JSON 字节流）
- 如果原函数已硬编码依赖，优先重构为可注入形式，而不是用
monkey patch等黑魔法
最易上手的替换方式是：把全局函数调用改为结构体字段方法调用，测试时给字段赋值 fake 函数。
测试最难的部分不是写断言，而是判断哪些逻辑值得测、哪些路径容易被忽略（比如nil 输入、并发竞争、超时回调）。先保证核心路径稳定，再逐步补全边界和错误分支。 
