Golang单元测试怎么写_必看教程

本文深入解析Go语言单元测试的硬性规范与最佳实践，直击开发者常踩的命名陷阱（如Test函数名、文件名和参数签名的严格要求）、表驱动测试中易被忽视的循环变量捕获问题（必须显式复制tt := tt）、断言信息的可读性设计、t.Error与t.Fatal的本质区别及其对调试效率的关键影响，以及并发测试下全局状态污染导致的偶发失败等顽疾，帮你避开go test“静默跳过”测试的坑，写出稳定、可维护、真正可靠的Go测试代码。

Test函数名和文件名必须严格匹配go test的识别规则

go test不会运行任何不满足硬性命名约定的测试函数，这不是警告，是直接忽略。

• Test必须大写开头，testAdd或Test_add（下划线后小写）全都不行
• 函数参数只能是*testing.T，多一个参数、少一个星号、类型写成testing.T（没指针）都会编译失败或静默跳过
• 文件名必须是xxx_test.go，test_xxx.go或xxx_test.golang无效
• 测试文件必须和被测代码在同一个包（package main 或 package utils），不能放错目录或改包名

常见错误现象：go test输出ok your/module 0.001s但根本没跑你写的测试——八成是文件名或函数签名错了。

用t.Run组织表驱动测试，别手写一堆TestXxx1/TestXxx2

多个输入组合共用同一逻辑时，硬拆成多个顶层测试函数会让维护成本飙升，且无法共享 setup/teardown。

• 把测试数据定义为结构体切片，每个元素带name字段，传给t.Run(name, ...)
• 循环内必须写tt := tt（显式复制循环变量），否则所有子测试会捕获最后一个tt值
• 断言里别只写got != want，要带上上下文：t.Errorf("case %q: got %v, want %v", tc.name, got, want)
• 如果被测函数返回error，检查逻辑得完整：if tc.wantErr && err == nil 和 if !tc.wantErr && err != nil 都要覆盖

示例中漏掉tt := tt会导致所有子测试都跑最后一组数据，这种 bug 很难一眼发现。

t.Error和t.Fatal行为差异直接影响调试效率

它们不是“轻重错误”的语义区别，而是执行流控制的根本不同。

• t.Error记录错误并继续执行当前测试函数的后续语句，适合想一次性看到多个断言失败点
• t.Fatal记录错误后立即return，终止当前测试函数，但不影响其他TestXxx函数运行
• 绝对不要在测试里调用log.Fatal或panic——这会杀死整个go test进程，其他测试全被跳过
• 子测试里用t.Fatal只杀当前t.Run分支，这是安全的；但顶层测试里滥用t.Fatal可能掩盖更多问题

比如在表驱动循环里写t.Fatal("input must be positive")，会导致后续所有测试用例被跳过，而不是只跳过当前 case。

别让全局状态或并发访问破坏测试稳定性

Go 测试默认并发执行所有TestXxx函数，这点常被忽略，直到出现偶发失败。

• 避免包级变量（如var cache map[string]int）在测试中被多个TestXxx读写，不加锁必出竞态
• 临时文件、mock server 端口、数据库连接等资源，必须在每个测试开始前初始化、结束后清理
• 如果 setup 成本高（如启动 HTTP mock），可用sync.Once缓存，但得确保 cleanup 不被遗漏，或改用t.Cleanup注册回调
• 不要依赖init()函数做测试准备——它只执行一次，无法隔离不同测试间的副作用

最隐蔽的问题：某个测试往全局 map 写了点东西，下一个测试读出来就 panic，但单独跑又没问题——这就是并发 + 共享状态的典型症状。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~