测试不是额外负担，而是让修改变轻
很多初学者学 Go 时会先写程序，再手动运行几次，看输出差不多就算完成。这个阶段可以理解，但一旦函数里出现业务规则，手动验证很快就不够用了。你今天改了折扣逻辑，明天改了分页边界，后天又修了一个空字符串问题，如果每次都靠肉眼看输出，迟早会漏。
Go 内置 testing 包，不需要安装测试框架。测试文件以 _test.go 结尾，测试函数以 Test 开头，执行 go test ./... 就能跑完整个模块。更重要的是，Go 社区非常偏爱表驱动测试：把输入、预期输出和用例名称放在一张表里，用同一段测试逻辑跑多组场景。
这种写法特别适合业务规则。规则越多，用例表越清楚。测试不只是检查代码对不对，也是在记录“我们认为这个函数应该如何表现”。
第一个普通测试
先写一个分页函数：
package pager
const (
defaultPage = 1
defaultSize = 20
maxSize = 100
)
func Normalize(page, size int) (int, int) {
if page <= 0 {
page = defaultPage
}
if size <= 0 {
size = defaultSize
}
if size > maxSize {
size = maxSize
}
return page, size
}
测试文件 pager_test.go：
package pager
import "testing"
func TestNormalize(t *testing.T) {
page, size := Normalize(-1, 500)
if page != 1 {
t.Fatalf("page = %d, want 1", page)
}
if size != 100 {
t.Fatalf("size = %d, want 100", size)
}
}
运行：
go test ./...
如果失败，t.Fatalf 会终止当前测试并输出信息。普通测试能用，但如果要覆盖更多场景，就会重复很多代码。
表驱动测试的基本形态
改成表驱动：
func TestNormalize(t *testing.T) {
tests := []struct {
name string
page int
size int
wantPage int
wantSize int
}{
{
name: "valid input",
page: 2,
size: 30,
wantPage: 2,
wantSize: 30,
},
{
name: "negative page uses default",
page: -1,
size: 30,
wantPage: 1,
wantSize: 30,
},
{
name: "too large size is capped",
page: 1,
size: 500,
wantPage: 1,
wantSize: 100,
},
{
name: "zero size uses default",
page: 1,
size: 0,
wantPage: 1,
wantSize: 20,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
gotPage, gotSize := Normalize(tt.page, tt.size)
if gotPage != tt.wantPage || gotSize != tt.wantSize {
t.Fatalf("Normalize(%d, %d) = (%d, %d), want (%d, %d)",
tt.page, tt.size, gotPage, gotSize, tt.wantPage, tt.wantSize)
}
})
}
}
这就是 Go 里很典型的测试风格。tests 是一个匿名结构体切片，每一项是一条用例。t.Run 创建子测试，失败时能看到具体用例名称。
表驱动测试的好处不是少写几行代码，而是让用例变成一张清单。新增边界条件时，只需要加一项。
测试错误路径
再写一个注册输入校验：
package account
import (
"fmt"
"strings"
)
type RegisterInput struct {
Email string
Password string
}
func ValidateRegister(input RegisterInput) error {
email := strings.TrimSpace(input.Email)
if email == "" {
return fmt.Errorf("email is required")
}
if !strings.Contains(email, "@") {
return fmt.Errorf("email is invalid")
}
if len(input.Password) < 8 {
return fmt.Errorf("password is too short")
}
return nil
}
测试：
func TestValidateRegister(t *testing.T) {
tests := []struct {
name string
input RegisterInput
wantErr bool
}{
{
name: "valid",
input: RegisterInput{
Email: "xiaolin@example.com",
Password: "secret123",
},
wantErr: false,
},
{
name: "missing email",
input: RegisterInput{
Password: "secret123",
},
wantErr: true,
},
{
name: "invalid email",
input: RegisterInput{
Email: "xiaolin",
Password: "secret123",
},
wantErr: true,
},
{
name: "short password",
input: RegisterInput{
Email: "xiaolin@example.com",
Password: "123",
},
wantErr: true,
},
}
for _, tt := range tests {
t.Run(tt.name, func(t *testing.T) {
err := ValidateRegister(tt.input)
if (err != nil) != tt.wantErr {
t.Fatalf("ValidateRegister() error = %v, wantErr %v", err, tt.wantErr)
}
})
}
}
(err != nil) != tt.wantErr 是常见写法，用来比较“是否出错”是否符合预期。如果你还关心具体错误类型，可以使用 errors.Is 或 errors.As。
使用辅助函数减少噪声
如果测试里有重复构造，可以写辅助函数：
func validInput() RegisterInput {
return RegisterInput{
Email: "xiaolin@example.com",
Password: "secret123",
}
}
或者写断言辅助：
func requireNoError(t *testing.T, err error) {
t.Helper()
if err != nil {
t.Fatalf("unexpected error: %v", err)
}
}
t.Helper() 很重要。它告诉测试框架这是辅助函数，失败时应该把行号指向调用处，而不是辅助函数内部。
使用：
func TestValidateRegisterValidInput(t *testing.T) {
err := ValidateRegister(validInput())
requireNoError(t, err)
}
Go 标准库没有内置 assert.Equal，这让一些人不习惯。你可以引入第三方断言库，但入门阶段建议先用标准库写一段时间。它会逼你把失败消息写清楚，也更容易理解测试本质。
测试未导出函数还是导出行为
测试文件可以写同包名：
package account
这样可以测试未导出函数。也可以写外部测试包：
package account_test
外部测试包只能访问导出 API，更像真实调用者。两种都合理。入门阶段如果你主要测试包内部规则，用同包测试更方便；如果你想保护公共 API 行为，用外部测试更稳。
不要为了测试而把所有函数都改成大写导出。导出是 API 承诺，不是测试开关。需要测试内部复杂规则时，同包测试就够了。
测试文件、临时目录和清理
测试文件读写时，不要污染项目目录。Go 提供 t.TempDir()：
func TestSaveFile(t *testing.T) {
dir := t.TempDir()
path := filepath.Join(dir, "data.txt")
err := os.WriteFile(path, []byte("hello"), 0644)
if err != nil {
t.Fatalf("write file: %v", err)
}
data, err := os.ReadFile(path)
if err != nil {
t.Fatalf("read file: %v", err)
}
if string(data) != "hello" {
t.Fatalf("data = %q, want hello", string(data))
}
}
测试结束后临时目录会自动清理。这样测试可以反复运行，不依赖本地手动准备文件，也不会留下垃圾。
小结
Go 测试的核心工具很简单：testing 包、go test ./...、t.Fatalf、t.Run 和表驱动用例。它们足够覆盖大多数入门和中小项目场景。
表驱动测试特别适合业务规则，因为它把输入和预期结果集中在一张表里。新增规则时加用例，修 bug 时先补失败用例，再改实现。这样代码越改越稳，而不是越改越怕。
测试不是为了追求数字，而是让你敢修改。一个函数只要有几个关键边界测试，后面重构时心里就有底。Go 把测试工具放进标准工具链，就是希望你把它当成日常动作，而不是上线前的仪式。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。