Go单元测试是什么 Go testing包基础用法解析

go单元测试需满足三条件：文件名以_test.go结尾且与被测代码同包同目录；函数名以test开头后接首字母大写的标识符；签名必须为func testxxx(t *testing.t)。

Go单元测试是用 testing 包 + _test.go 文件验证函数/方法行为是否符合预期的轻量级机制，不是框架，不依赖第三方也能开跑。

怎么写一个能被 go test 识别的测试函数

必须同时满足三个硬性条件，缺一不可：

• 文件名以 _test.go 结尾（如 calc_test.go），且和被测代码在**同一包、同一目录**下
• 函数名以大写 Test 开头，后接**首字母大写的标识符**（TestAdd ✅，testAdd ❌，Test_add ❌）
• 函数签名唯一合法形式：func TestXxx(t *testing.T)，参数类型不能是 *testing.B 或其他

一旦违反任一规则，go test 就会静默跳过——不会报错，只显示 no tests to run 或直接 PASS，这是新手最常卡住的地方。

t.Error、t.Fatal、t.Errorf 到底该用哪个

它们都用于报告失败，但**执行流控制完全不同**：

• t.Error / t.Errorf：记录错误并**继续执行当前测试函数剩余代码**，适合检查多个断言（比如同时校验返回值和 error 是否为空）
• t.Fatal / t.Fatalf：记录错误后**立刻终止当前测试函数**，不执行后续语句，适合前置校验失败（如 setup 失败、依赖未就绪）

别滥用 Fatal：它不会中断整个测试套件，只停当前函数；但若在循环里误用，会导致后续测试 case 被跳过，掩盖问题。

为什么 go test 默认不输出日志，-v 又突然全出来了

t.Log 和 t.Logf 的日志默认是“静默”的——只有测试失败或显式加了 -v 才打印。这是 Go 的刻意设计：

• 避免成功测试刷屏干扰，保持输出干净
• 防止日志 IO 拖慢基准测试（Benchmark 函数里 Log 却总会输出，因为性能测量需稳定环境）
• 调试时可放心加 t.Logf("input: %v, got: %v", in, out)，上线前无需删，不影响正常运行

顺带一提：go test -v 还会显示每个 TestXxx 的执行顺序和耗时，对排查超时或阻塞很有用。

表格驱动测试不是炫技，是防漏测的刚需

当一个函数有多个分支（比如不同输入类型、边界值、error 场景），手写一堆 TestXxx 函数既重复又难维护。表格驱动用 slice + Struct 把 case 统一管理：

func TestParseURL(t *testing.T) { 	tests := []struct { 		name     string 		input    string 		wantHost string 		wantErr  bool 	}{ 		{"empty", "", "", true}, 		{"valid", "https://example.com", "example.com", false}, 		{"no-scheme", "example.com", "", true}, 	} 	for _, tt := range tests { 		t.Run(tt.name, func(t *testing.T) { 			host, err := ParseURL(tt.input) 			if (err != nil) != tt.wantErr { 				t.Fatalf("expected err=%v, got %v", tt.wantErr, err) 			} 			if host != tt.wantHost { 				t.Errorf("host = %v, want %v", host, tt.wantHost) 			} 		}) 	} }

关键点：t.Run 让每个子 case 独立计时、独立失败，且名字可读；但注意——子测试里不能再调 t.Parallel() 除非你确认所有 case 完全无共享状态，否则容易引发竞态。

最容易被忽略的其实是清理：测试中打开的文件、启动的 goroutine、注册的全局 hook，如果没用 t.Cleanup 收尾，会在后续测试里悄悄累积副作用。哪怕只是临时改了一个包级变量，也得记得还原。