Golang单元测试与压力测试：提升语言学习项目质量的必备工具

在Go语言项目中，测试环节往往被低估，但实际踩过的坑能写满一本小册子。先说个核心判断：项目上线前不跑go test，等于没测；只跑go test -bench=.当压力测试，等于白压。下面从几个关键点展开，帮你避开常见误区。

go test 不执行测试函数？先查这四个硬约束

终端输出no test files或undefined: XXX？别急着找逻辑问题，多半是被Go的测试机制卡住了。四个硬性条件需要逐一核对：

• 文件名必须是xxx_test.go，不能是test_xxx.go或xxx.test.go
• 测试函数名必须以大写Test开头，且第二个字母不能是小写（TestAdd ✅，Testadd ❌，Testint ❌）
• 函数签名必须是func TestXxx(t *testing.T)，参数类型写错成*testing.B或自定义结构体，函数会被静默跳过
• 测试文件和被测代码必须在同一个包下（package user的user.go，测试必须写在同目录的user_test.go中，且声明package user）

导出问题也常被忽略：如果被测函数首字母小写（如calc()），它在同包内可被测试调用；但若误建了user_test包（外部测试），那它就不可见——除非你真需要打破循环依赖，否则别这么干。

表驱动测试写法翻车最多的地方

用[]struct{ name, input, want string } + t.Run是标准写法，但实际写出来常漏掉关键细节。每个case的name必须能直接读出场景，比如"returns_error_on_empty_name"，而不是"case1"——失败时你能一眼定位问题域。输入和预期值必须显式写出，别在循环里算expected := tc.a + tc.b，否则失败日志只报got 5, want ???。

必须包含非法输入case：空字符串、负ID、nil指针、超长字段——这些才是线上panic的主力。闭包陷阱也需要注意：循环中直接用tc调t.Run，所有子测试实际跑的都是最后一个tc的数据；得写成tc := tc显式复制变量。复杂返回值别无脑==：比如返回map[string]interface{}，优先比关键字段（err == nil、user.ID > 0），而非全量reflect.DeepEqual——后者会让错误信息淹没在几百行diff里。

Benchmark 函数不是压力测试，别拿它当并发接口压测

go test -bench=.跑的是基准测试（benchmark），目标是单次函数调用的CPU/内存开销，不是模拟真实并发请求。它用*testing.B，会自动循环调用并统计均值，但完全不涉及网络、连接池、goroutine生命周期管理。基准测试不能手动调用，必须由go test -bench启动；手动创建*testing.B会导致b.N=0、计时失效、结果失真。

真正压测HTTP接口，得用独立工具：比如go-wrk、hey，或自己写带连接复用的goroutine循环。压测脚本里不复用http.Client，每轮新建client→连接泄露→内存暴涨→系统kill进程。本地压测高并发（如-c 1000）前，务必加runtime.GOMAXPROCS(4)控制调度，否则goroutine创建速度远超调度能力，结果测的不是业务，是调度器瓶颈。关注goroutine count变化趋势：压测前后用debug.ReadGCStats或pprof查/debug/pprof/goroutine?debug=2，持续上涨就是泄露。基准测试里b.ResetTimer()和b.StopTimer()的位置很关键：耗时操作（如初始化DB连接）必须放在b.StopTimer()之后、b.ResetTimer()之前，否则会把setup时间算进benchmark结果。

覆盖率数字高 ≠ 质量高，重点盯住错误路径

go test -cover输出一个百分比，但这个数字本身没意义。真正要命的是那些没覆盖的分支：if-else的else分支、switch的default、error != nil的处理块——这些才是线上crash的温床。panic路径、defer中recover的逻辑、context超时退出分支，往往一行没覆盖，上线后就timeout。用go tool cover -html=cover.out打开报告，直接点红块看哪行没执行，而不是盯着summary数字自我安慰。最常被忽略的一点：表驱动测试里的每个t.Run子测试，都必须独立触发所有分支路径。一个case覆盖了err == nil，不代表另一个case就覆盖了err != nil——它们是隔离执行的。