Go语言的一大设计哲学是把工程化能力内置到语言本身，测试就是最典型的例子。很多语言需要引入JUnit、pytest这样的第三方库才能写测试，而Go只需要标准库中的testing包配合go test命令，就能完成单元测试、基准测试、示例测试乃至覆盖率统计的全部工作。这篇文章会从零开始介绍Go测试的基本概念、文件组织方式和具体写法，并覆盖表驱动测试、子测试等社区常用的实践技巧。
Go测试的基本概念与文件组织
首先明确一个定义：单元测试是对程序中最小可测试单元（通常是一个函数或一个方法）进行正确性验证的过程。在Go中，单元测试代码和被测代码放在同一个包目录下，测试文件以_test.go结尾。比如math.go对应的测试文件通常命名为math_test.go。这种就近放置的方式让测试代码可以访问包内的私有函数，同时_test.go文件在执行go build时会被排除，不会编译进最终的二进制产物。
编写测试函数必须遵守固定的签名规范：函数名以大写字母Test开头，参数类型必须是*testing.T。Go的测试框架通过反射扫描这些签名来识别测试用例，任何不满足规范的函数都会被静默忽略。看一个最简单的例子：
// calc.go
package calc
// Add 返回两个整数之和
func Add(a, b int) int {
return a + b
}
// calc_test.go
package calc
import "testing"
func TestAdd(t *testing.T) {
got := Add(2, 3)
if got != 5 {
t.Errorf("Add(2, 3) = %d; 期望 5", got)
}
}
在终端执行go test命令后，如果输出ok说明测试通过，输出FAIL则表示有用例失败。这里需要区分两个最常用的报告方法：t.Errorf用于报告错误但继续执行后续断言，适合收集全部失败信息一次性修复；t.Fatalf则会立即终止当前测试函数，适合后续逻辑依赖前面结果的场景。初学者常见的误区是把两者混用，导致一个前置条件失败后程序panic，反而掩盖了真正的错误原因。
表驱动测试：Go社区的标准写法
如果每个用例都写一个独立的测试函数，文件会迅速膨胀。Go社区（包括官方文档）最推荐的做法是表驱动测试：把多组输入和期望输出组织成一个切片，然后循环执行断言。这种写法的好处是新增用例只需要往表里加一行数据，测试逻辑本身完全不用改。
package calc
import "testing"
func TestAddTable(t *testing.T) {
tests := []struct {
name string
a, b int
want int
}{
{"两个正数", 2, 3, 5},
{"负数相加", -2, -3, -5},
{"零值", 0, 0, 0},
{"正负混合", -5, 5, 0},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
if got := Add(tt.a, tt.b); got != tt.want {
t.Errorf("Add(%d, %d) = %d; 期望 %d", tt.a, tt.b, got, tt.want)
}
})
}
}
上面代码中用到的t.Run会为每组数据创建一个子测试。子测试的价值在于：执行go test -v时每组用例的结果会独立展示，某组数据失败能精确定位到name标识的具体场景，而不是只看到一行笼统的失败信息。此外还可以通过go test -run TestAddTable/负数相加的形式只执行某一个特定子测试，这在调试边界用例时非常高效。
每个测试结构体里加一个name字段是社区约定俗成的习惯，用中文描述场景的好处是失败输出直接可读。表驱动测试同样适用于需要错误返回值的函数，只需在结构体中增加一个err error或wantErr bool字段，循环中判断err != nil是否与预期一致即可。
基准测试与测试覆盖率
除了验证正确性，testing包还内置了性能测试能力。基准测试函数以Benchmark开头，参数类型是*testing.B，核心是把被测代码放在b.N次循环里执行，让框架自动调整循环次数以获得稳定数据：
package calc
import "testing"
func BenchmarkAdd(b *testing.B) {
for i := 0; i < b.N; i++ {
Add(i, i)
}
}
执行go test -bench=. -benchmem即可输出每次操作的纳秒耗时以及内存分配次数和字节数。注意基准测试函数中只应包含被测代码本身，任何初始化工作都应该放在循环外，否则测出来的数据会失真。当需要对比两个实现的性能差异时，基准测试提供的数据远比主观感觉可靠。
测试覆盖率反映测试代码执行过了多少比例的业务代码，执行go test -cover会输出百分比结果。如果想看逐行明细，可以加-coverprofile=cover.out生成覆盖文件，再用go tool cover -html=cover.out在浏览器中查看，被覆盖的行会标绿，未覆盖的行标红。不过需要提醒的是，覆盖率只是参考指标，覆盖率高不代表测试质量高——断言写得潦草的测试同样能拉高覆盖率，却测不出任何问题。
最后补充几个实用技巧：go test -v显示每个用例的详细结果；go test ./...递归执行整个项目所有包的测试；测试函数中可以用t.Skip跳过某些在特定环境不可用的用例；如果被测对象依赖数据库等外部资源，可以在测试中通过接口抽象进行模拟，或者使用go-sqlmock这类辅助库。养成先写测试再改代码的习惯，配合go test的快速反馈循环，能显著减少低级bug并让重构更有底气。