Go初级项目如何写单元测试_Go测试实战示例

Go单元测试需满足:文件名以_test.go结尾、函数名以Test开头、参数为*testing.T且无返回值;测试须与被测代码同包;用t.Fatal/t.Errorf处理错误分支;推荐表驱动测试和接口+fake替换外部依赖。

Go 单元测试从零跑通 go test

Go 的单元测试不需要第三方框架,go test 命令开箱即用。只要文件名以 _test.go 结尾、函数名以 Test 开头、参数为 *testing.T,就能被识别并执行。

常见错误是把测试文件放在错误目录(比如和 main.go 同级但没加 _test.go 后缀),或者函数签名写成 func TestXxx()(漏掉 *testing.T 参数)——这时 go test 会直接跳过,不报错也不运行。

  • 测试文件必须和被测代码在同一个包下(同目录、同 package 声明)
  • 测试函数不能有返回值,必须是 func TestXxx(t *testing.T)
  • 运行全部测试:go test;只跑某个测试:go test -run TestCalcSum

如何测一个带 error 返回的函数

很多初级项目里,函数会返回 (int, error) 这类组合。测试时不能只校验正常路径,更要覆盖 error != nil 的分支,否则上线后 panic 或静默失败很难排查。

关键点在于:用 t.Fatalt.Errorf 主动中断或记录失败,而不是靠 if err != nil { panic(...) } ——测试中 panic 会导致整个测试提前终止,后续用例无法执行。

func TestDivide(t *testing.T) {
    result, err := Divide(10, 0)
    if err == nil {
        t.Fatal("expected error when dividing by zero")
    }
    if result != 0 {
        t.Errorf("expected 0, got %d", result)
    }

    result, err = Divide(10, 2)
    if err != nil {
        t.Fatalf("unexpected error: %v", err)
    }
    if result != 5 {
        t.Errorf("expected 5, got %d", result)
    }
}

表驱动测试让多个输入场景一目了然

当一个函数要处理多种边界情况(空字符串、负数、超大值),硬写一堆 TestXxx1/TestXxx2 很难维护。Go 社区惯用「表驱动」方式:用切片定义测试用例,循环执行。

好处是新增 case 只需往表里加一行,逻辑复用,输出也更清晰(失败时能直接看到是哪组输入出问题)。

  • 每个 testCase 字段名建议语义化(如 name, input, expected, shouldErr
  • t.Run 包一层,让每个子测试独立运行、独立计时、失败时显示具体 name
  • 避免在循环里直接用 range 变量地址(闭包陷阱),应显式赋值:tc := tc
func TestParseInt(t *testing.T) {
    

tests := []struct { name string input string expected int shouldErr bool }{ {"empty", "", 0, true}, {"valid", "42", 42, false}, {"negative", "-7", -7, false}, {"invalid", "abc", 0, true}, } for _, tc := range tests { tc := tc // 防止 goroutine 闭包捕获循环变量 t.Run(tc.name, func(t *testing.T) { result, err := ParseInt(tc.input) if tc.shouldErr { if err == nil { t.Fatal("expected error but got nil") } return } if err != nil { t.Fatalf("unexpected error: %v", err) } if result != tc.expected { t.Errorf("expected %d, got %d", tc.expected, result) } }) } }

测试依赖外部服务?用接口 + fake 替换

初级项目常直接调用 http.Getos.ReadFile 或数据库操作,导致测试变慢、不稳定、需要预置环境。正确做法是把依赖抽象成接口,在测试时注入 fake 实现。

例如,一个读配置的函数如果依赖 os.ReadFile,就把它改成接收一个 func(string) ([]byte, error) 类型的读取器,测试时传入闭包即可控制返回内容。

  • 不要在测试里启动真实 HTTP server 或连接真实 DB,除非你明确在写集成测试
  • fake 实现越简单越好,只模拟必要行为(比如固定返回 JSON 字节流)
  • 如果原函数已硬编码依赖,优先重构为可注入形式,而不是用 monkey patch 等黑魔法

最易上手的替换方式是:把全局函数调用改为结构体字段方法调用,测试时给字段赋值 fake 函数。

测试最难的部分不是写断言,而是判断哪些逻辑值得测、哪些路径容易被忽略(比如 nil 输入、并发竞争、超时回调)。先保证核心路径稳定,再逐步补全边界和错误分支。