Go 测试体系——单元测试、表驱动测试与 Mock

摘要

Go 内置了完整的测试框架——testing 包和 go test 命令，无需引入外部测试框架即可编写单元测试、基准测试和示例测试。但 Go 测试生态远不止于此：表驱动测试（Table-driven Tests）是 Go 社区最广泛使用的测试组织模式，能以极少的代码覆盖大量边界条件；testify 库提供了流畅的断言 API，让测试代码更可读；gomock 和接口 Mock 机制让依赖隔离成为可能，是 Clean Architecture 中 Use Case 层可测试性的关键保障。本文从 Go 测试的基础设施（_test.go 文件、testing.T）出发，系统梳理表驱动测试的最佳实践、子测试（t.Run）的并行化、Mock 的设计哲学与 gomock 的使用，以及测试覆盖率、go test 常用标志等工程实践。

第 1 章 Go 测试基础：testing 包与 go test

1.1 测试文件的约定

Go 测试代码有严格的文件命名和函数命名约定：

mypackage/
├── user.go          # 生产代码
├── user_test.go     # 测试代码（与生产代码同包）
└── user_external_test.go  # 黑盒测试（package usertest，不可见内部细节）

文件命名：测试文件必须以 _test.go 结尾，go build 不会将其编译进最终二进制，只有 go test 才会编译它们。

包名的两种约定：

package user（白盒测试）：与被测代码同包，可以访问未导出的字段和函数，适合测试内部实现细节；
package user_test（黑盒测试）：不同包，只能访问导出 API，模拟外部调用者视角，更贴近真实使用场景。

函数命名规则：

// 单元测试：Test 前缀 + 大写字母开头的函数名
func TestFunctionName(t *testing.T) { ... }
 
// 基准测试：Benchmark 前缀
func BenchmarkFunctionName(b *testing.B) { ... }
 
// 示例测试：Example 前缀（同时作为文档）
func ExampleFunctionName() {
    fmt.Println(FunctionName("input"))
    // Output:
    // expected output
}
 
// 模糊测试（Go 1.18+）：Fuzz 前缀
func FuzzFunctionName(f *testing.F) { ... }

1.2 testing.T 的核心方法

func TestUserCreate(t *testing.T) {
    // t.Error/Errorf：记录失败，但测试继续执行
    if got != want {
        t.Errorf("got %v, want %v", got, want)
    }
    
    // t.Fatal/Fatalf：记录失败并立即停止当前测试函数（执行 defer 后退出）
    user, err := CreateUser(ctx, req)
    if err != nil {
        t.Fatalf("CreateUser failed: %v", err)  // 后续依赖 user 的断言都不会执行
    }
    
    // t.Log/Logf：记录日志（只在测试失败或 -v 模式下显示）
    t.Logf("created user: %+v", user)
    
    // t.Skip：跳过测试（如外部依赖不可用时）
    if os.Getenv("DATABASE_URL") == "" {
        t.Skip("DATABASE_URL not set, skipping integration test")
    }
    
    // t.Parallel：允许该测试与其他 t.Parallel() 测试并行运行
    t.Parallel()
    
    // t.Cleanup：注册清理函数（测试结束时执行，类似 defer 但绑定到测试生命周期）
    db := setupTestDB(t)
    t.Cleanup(func() { db.Close() })
}

t.Helper()：标记当前函数为测试辅助函数，失败时 Go 会显示调用 helper 的那行代码（而不是 helper 内部），让错误定位更准确：

// 没有 t.Helper()：失败信息指向 assertEqual 内部第 X 行
// 有 t.Helper()：失败信息指向 TestXxx 中调用 assertEqual 的那行
 
func assertEqual(t *testing.T, got, want interface{}) {
    t.Helper()  // 关键：标记为辅助函数
    if got != want {
        t.Errorf("got %v, want %v", got, want)
    }
}

1.3 go test 常用标志

# 运行当前包的所有测试
go test ./...           # 递归运行所有包
go test ./internal/...  # 运行指定目录
 
# 过滤运行特定测试（支持正则）
go test -run TestUser           # 运行所有匹配 "TestUser" 的测试
go test -run TestUser/create    # 运行 TestUser 中名为 "create" 的子测试
 
# 详细输出（显示每个测试的 PASS/FAIL 和 t.Log 输出）
go test -v ./...
 
# 数据竞争检测（CI 中强烈推荐）
go test -race ./...
 
# 测试覆盖率
go test -cover ./...                          # 打印覆盖率百分比
go test -coverprofile=coverage.out ./...      # 生成覆盖率数据文件
go tool cover -html=coverage.out              # 在浏览器中可视化查看
 
# 超时控制（默认 10 分钟）
go test -timeout 30s ./...
 
# 基准测试（默认不运行）
go test -bench=.          # 运行所有基准测试
go test -bench=BenchmarkXxx -benchmem  # 同时显示内存分配统计
 
# 并行度控制
go test -parallel 4 ./...  # 最多 4 个并行测试

第 2 章表驱动测试：Go 的测试范式

2.1 什么是表驱动测试，为什么是 Go 的标准范式

表驱动测试（Table-driven Tests） 是一种将测试用例组织为数据表（通常是 slice of struct）的测试模式：每行是一个测试用例，包含输入和期望输出；测试函数遍历表中每行，执行相同的测试逻辑。

不用表驱动时，测试一个函数的多个边界条件需要重复写大量结构相似的代码：

// 不使用表驱动（冗余、难维护）
func TestAdd(t *testing.T) {
    result := Add(1, 2)
    if result != 3 {
        t.Errorf("Add(1, 2) = %d, want 3", result)
    }
    
    result = Add(-1, 1)
    if result != 0 {
        t.Errorf("Add(-1, 1) = %d, want 0", result)
    }
    
    result = Add(0, 0)
    if result != 0 {
        t.Errorf("Add(0, 0) = %d, want 0", result)
    }
    // 每增加一个用例都要写 4 行代码...
}

使用表驱动测试：

// 表驱动测试（清晰、易扩展）
func TestAdd(t *testing.T) {
    tests := []struct {
        name string  // 测试用例名称（用于 t.Run 和错误定位）
        a, b int
        want int
    }{
        {"positive numbers", 1, 2, 3},
        {"negative and positive", -1, 1, 0},
        {"both zero", 0, 0, 0},
        {"large numbers", 1000000, 2000000, 3000000},
        {"overflow boundary", math.MaxInt64, 1, math.MinInt64},  // 边界条件
    }
    
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Add(tt.a, tt.b)
            if got != tt.want {
                t.Errorf("Add(%d, %d) = %d, want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

表驱动测试的核心优势：

添加新用例只需在表中添加一行，不需要修改测试逻辑；
测试用例集中在一处，边界条件一目了然，便于 code review；
每个用例通过 t.Run 独立运行，失败时精确定位到用例名；
可以方便地并行化（见下文）。

2.2 t.Run 子测试：独立命名与并行化

t.Run 为每个表中的用例创建一个子测试（Subtest），子测试有独立的名称和独立的 *testing.T：

for _, tt := range tests {
    tt := tt  // Go 1.21 之前必须做的变量捕获（防止循环变量共享）
    t.Run(tt.name, func(t *testing.T) {
        t.Parallel()  // 子测试之间并行运行（提升测试速度）
        
        got := expensiveCompute(tt.input)
        if got != tt.want {
            t.Errorf("got %v, want %v", got, tt.want)
        }
    })
}

子测试的运行控制：

# 只运行 TestAdd 中名为 "positive numbers" 的子测试
go test -run "TestAdd/positive_numbers"  # 注意：空格被转换为下划线
 
# 运行所有包含 "overflow" 的子测试
go test -run ".*/overflow"

2.3 测试夹具（Test Fixtures）

测试夹具指测试所需的初始化数据和环境。Go 提供了多种方式管理夹具：

方式一：TestMain 全局夹具

// 在包级别 TestMain 中初始化和清理全局资源
func TestMain(m *testing.M) {
    // 初始化：在所有测试前运行
    db := setupTestDatabase()
    
    // 运行所有测试
    exitCode := m.Run()
    
    // 清理：在所有测试后运行
    db.Close()
    dropTestDatabase()
    
    os.Exit(exitCode)
}

方式二：t.Cleanup 每个测试的清理

func TestUserRepository(t *testing.T) {
    // 为这个测试创建专用的数据库事务，测试结束后回滚
    tx, err := db.BeginTx(context.Background(), nil)
    require.NoError(t, err)
    t.Cleanup(func() { tx.Rollback() })  // 测试结束时自动回滚，隔离测试数据
    
    repo := NewUserRepository(tx)
    // ...
}

方式三：helper 函数

// 封装通用的测试初始化逻辑
func newTestServer(t *testing.T) *httptest.Server {
    t.Helper()
    
    handler := setupHandler()
    srv := httptest.NewServer(handler)
    t.Cleanup(srv.Close)  // 测试结束时自动关闭 server
    
    return srv
}
 
func TestUserAPI(t *testing.T) {
    srv := newTestServer(t)
    
    resp, err := http.Get(srv.URL + "/users/1")
    // ...
}

第 3 章 testify：流畅的断言库

3.1 为什么需要 testify

标准库的 testing.T 只提供 t.Error、t.Fatal 等基础方法，没有内置断言（assertion）——每次比较都需要手写 if got != want { t.Errorf(...) }。github.com/stretchr/testify 是 Go 最流行的测试辅助库，提供：

assert：失败后继续执行（底层调用 t.Errorf）；
require：失败后立即停止（底层调用 t.Fatalf）；
mock：Mock 支持（较少使用，通常用 gomock）；
suite：测试套件（xUnit 风格）。

import (
    "testing"
    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/require"
)
 
func TestUserService_Register(t *testing.T) {
    svc := NewUserService(mockRepo)
    
    user, err := svc.Register(ctx, RegisterRequest{
        Email: "test@example.com",
        Name:  "Test User",
    })
    
    // require：如果 err != nil，立即停止（后续断言依赖 user 不为 nil）
    require.NoError(t, err)
    require.NotNil(t, user)
    
    // assert：失败后继续执行（检查多个字段）
    assert.Equal(t, "test@example.com", user.Email)
    assert.Equal(t, "Test User", user.Name)
    assert.NotEmpty(t, user.ID)
    assert.WithinDuration(t, time.Now(), user.CreatedAt, time.Second)
}

assert vs require 的选择原则：

后续断言依赖当前断言的结果（如需要一个非 nil 的对象来访问字段）：用 require；
各断言独立，失败后仍然有意义继续检查其他字段：用 assert。

3.2 testify 常用断言

// 相等性
assert.Equal(t, expected, actual)           // 深度相等（支持 struct、slice、map）
assert.NotEqual(t, expected, actual)
assert.EqualValues(t, expected, actual)     // 允许类型不同但值相等（int32 vs int64）
 
// nil 检查
assert.Nil(t, err)
assert.NotNil(t, result)
 
// 布尔
assert.True(t, condition)
assert.False(t, condition)
 
// 字符串
assert.Contains(t, "hello world", "world")
assert.HasPrefix(t, "hello world", "hello")
 
// 数字比较
assert.Greater(t, 10, 5)
assert.GreaterOrEqual(t, 10, 10)
assert.InDelta(t, 3.14159, math.Pi, 0.001)  // 浮点数近似比较
 
// 集合
assert.Len(t, slice, 3)
assert.Empty(t, slice)
assert.ElementsMatch(t, []int{1, 2, 3}, []int{3, 1, 2})  // 顺序无关的相等
 
// 错误
assert.Error(t, err)                         // err != nil
assert.NoError(t, err)                       // err == nil
assert.ErrorIs(t, err, target)              // errors.Is(err, target)
assert.ErrorAs(t, err, &target)             // errors.As(err, &target)
 
// panic
assert.Panics(t, func() { dangerousFunc() })
assert.PanicsWithValue(t, "expected panic msg", func() { ... })

第 4 章 Mock：依赖隔离的关键

4.1 为什么需要 Mock

单元测试的核心要求是隔离（Isolation）：测试一个函数时，不应该真正调用其依赖（数据库、外部 API、文件系统），原因：

速度：真实数据库调用需要 10-100ms，Mock 调用需要 < 1µs；
确定性：外部依赖可能有网络抖动、数据库状态变化，Mock 结果完全可控；
边界条件：Mock 可以模拟真实环境难以复现的情况（数据库超时、返回错误等）；
独立性：单元测试不应该依赖外部服务的可用性。

Go 的接口机制让 Mock 非常自然：只要被测代码通过接口而非具体类型依赖外部服务，就可以在测试时注入 Mock 实现。

4.2 手写 Mock：最简单的方式

对于简单接口，手写 Mock 是最直接的方式：

// 被测代码依赖的接口
type UserRepository interface {
    FindByID(ctx context.Context, id string) (*User, error)
    Save(ctx context.Context, user *User) error
}
 
// 手写 Mock（测试文件中）
type mockUserRepository struct {
    findByIDFunc func(ctx context.Context, id string) (*User, error)
    saveFunc     func(ctx context.Context, user *User) error
    
    // 记录调用情况（用于验证）
    saveCalled int
    savedUsers []*User
}
 
func (m *mockUserRepository) FindByID(ctx context.Context, id string) (*User, error) {
    if m.findByIDFunc != nil {
        return m.findByIDFunc(ctx, id)
    }
    return nil, ErrNotFound
}
 
func (m *mockUserRepository) Save(ctx context.Context, user *User) error {
    m.saveCalled++
    m.savedUsers = append(m.savedUsers, user)
    if m.saveFunc != nil {
        return m.saveFunc(ctx, user)
    }
    return nil
}
 
// 使用手写 Mock 的测试
func TestUserService_Register_EmailDuplicate(t *testing.T) {
    // 准备：FindByID 返回一个已存在的用户（模拟邮箱重复场景）
    mockRepo := &mockUserRepository{
        findByIDFunc: nil,
    }
    mockRepo.findByIDFunc = func(ctx context.Context, id string) (*User, error) {
        return &User{Email: "test@example.com"}, nil  // 用户已存在
    }
    
    svc := NewUserService(mockRepo)
    _, err := svc.Register(ctx, RegisterRequest{Email: "test@example.com"})
    
    assert.ErrorIs(t, err, ErrEmailDuplicate)
    assert.Equal(t, 0, mockRepo.saveCalled)  // 验证 Save 没有被调用
}

手写 Mock 的优点是完全可控、无外部依赖；缺点是当接口方法多时，维护成本高。

4.3 gomock：代码生成的 Mock 框架

go.uber.org/mock（原 github.com/golang/mock，已由 Uber 接管维护）是 Go 最主流的 Mock 框架，通过代码生成自动创建 Mock 实现：

安装与生成：

go install go.uber.org/mock/mockgen@latest
 
# 方式一：源码模式（从接口定义文件生成）
mockgen -source=internal/port/repository.go -destination=internal/mocks/mock_repository.go -package=mocks
 
# 方式二：反射模式（指定包路径和接口名）
mockgen -destination=internal/mocks/mock_repo.go -package=mocks \
    github.com/myorg/myservice/internal/port UserRepository
 
# 在源文件中用 go:generate 注释，然后运行 go generate ./...
//go:generate mockgen -source=$GOFILE -destination=../mocks/mock_$GOFILE -package=mocks

生成的 Mock 代码使用：

import (
    "testing"
    "go.uber.org/mock/gomock"
    "github.com/myorg/myservice/internal/mocks"
)
 
func TestUserService_Register(t *testing.T) {
    ctrl := gomock.NewController(t)
    // ctrl.Finish() 在测试结束时自动验证所有期望是否满足（Go 1.14+ 自动调用）
    
    mockRepo := mocks.NewMockUserRepository(ctrl)
    
    // 设置期望：FindByEmail 被调用一次，返回 ErrNotFound
    mockRepo.EXPECT().
        FindByEmail(gomock.Any(), "new@example.com").  // gomock.Any() 匹配任意 ctx
        Return(nil, ErrNotFound).
        Times(1)  // 期望恰好被调用 1 次
    
    // 设置期望：Save 被调用一次，验证参数并返回 nil
    mockRepo.EXPECT().
        Save(gomock.Any(), gomock.AssignableToTypeOf(&User{})).
        DoAndReturn(func(ctx context.Context, u *User) error {
            // 可以在这里验证传入的 user 对象
            assert.Equal(t, "new@example.com", u.Email)
            u.ID = "generated-id"  // 模拟数据库生成 ID
            return nil
        }).
        Times(1)
    
    svc := NewUserService(mockRepo)
    user, err := svc.Register(context.Background(), RegisterRequest{
        Email: "new@example.com",
        Name:  "New User",
    })
    
    require.NoError(t, err)
    assert.Equal(t, "generated-id", user.ID)
}

gomock 常用 Matcher：

// 精确匹配
gomock.Eq("exact value")
 
// 任意值
gomock.Any()
 
// 类型匹配
gomock.AssignableToTypeOf(&User{})
 
// 自定义 Matcher
gomock.Cond(func(x interface{}) bool {
    user, ok := x.(*User)
    return ok && user.Email != ""
})
 
// 调用次数控制
.Times(1)       // 恰好 1 次
.AnyTimes()     // 任意次数（包括 0 次）
.MinTimes(1)    // 至少 1 次
.MaxTimes(3)    // 最多 3 次
.AtLeastOnce()  // 至少 1 次

4.4 httptest：HTTP 集成测试

net/http/httptest 是测试 HTTP handler 的标准工具，无需启动真实服务器：

func TestUserHandler_Get(t *testing.T) {
    // 创建测试用的 HTTP server
    handler := NewUserHandler(mockService)
    srv := httptest.NewServer(handler)
    defer srv.Close()
    
    // 发送真实 HTTP 请求
    resp, err := http.Get(srv.URL + "/users/user-123")
    require.NoError(t, err)
    defer resp.Body.Close()
    
    assert.Equal(t, http.StatusOK, resp.StatusCode)
    
    var user User
    require.NoError(t, json.NewDecoder(resp.Body).Decode(&user))
    assert.Equal(t, "user-123", user.ID)
}
 
// 或者用 httptest.NewRecorder 直接测试 Handler 函数（更轻量）
func TestUserHandler_Get_NotFound(t *testing.T) {
    mockSvc := mocks.NewMockUserService(ctrl)
    mockSvc.EXPECT().GetUser(gomock.Any(), "nonexistent").Return(nil, ErrUserNotFound)
    
    handler := NewUserHandler(mockSvc)
    
    req := httptest.NewRequest("GET", "/users/nonexistent", nil)
    w := httptest.NewRecorder()
    
    handler.ServeHTTP(w, req)
    
    assert.Equal(t, http.StatusNotFound, w.Code)
}

第 5 章测试覆盖率与 CI 集成

5.1 理解测试覆盖率

# 生成覆盖率报告
go test -coverprofile=coverage.out ./...
go tool cover -func=coverage.out   # 按函数显示
go tool cover -html=coverage.out   # 浏览器可视化
 
# 查看整体覆盖率
go test -cover ./...
# ok   github.com/myorg/myservice/internal/usecase  83.2% of statements

覆盖率的正确理解：高覆盖率不等于高质量测试——100% 覆盖率但只测试正常路径，不测试错误路径，仍然是低质量测试。覆盖率是下限检测工具（发现根本没有测试的代码），不是质量保证工具。

Go 提供了多种覆盖率模式：

set（默认）：每行是否被执行过（是/否）；
count：每行被执行的次数；
atomic：并发安全的计数（用于并发测试的覆盖率统计）。

5.2 CI 中的测试最佳实践

# GitHub Actions 示例：完整的 Go 测试 CI
name: Test
 
on: [push, pull_request]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v4
        with:
          go-version: '1.21'
      
      # 验证依赖完整性
      - run: go mod verify
      
      # 代码格式检查
      - run: gofmt -l . | tee /dev/stderr | [ $(wc -l) -eq 0 ]
      
      # 静态分析
      - run: go vet ./...
      
      # 单元测试（带 race 检测和覆盖率）
      - run: go test -race -coverprofile=coverage.out -covermode=atomic ./...
      
      # 覆盖率上报（如 Codecov）
      - uses: codecov/codecov-action@v3
        with:
          files: ./coverage.out

5.3 集成测试的隔离策略

集成测试（需要真实数据库、外部服务）应该与单元测试隔离：

// 方案一：Build tags 隔离
//go:build integration
 
package repository_test
 
func TestUserRepository_FindByID_Integration(t *testing.T) {
    // ...
}

# 正常测试（跳过集成测试）
go test ./...
 
# 运行集成测试
go test -tags=integration ./...

// 方案二：环境变量控制
func TestUserRepository_Integration(t *testing.T) {
    dsn := os.Getenv("TEST_DATABASE_URL")
    if dsn == "" {
        t.Skip("TEST_DATABASE_URL not set, skipping integration test")
    }
    // ...
}

总结

本篇系统梳理了 Go 测试体系的完整工具链：

testing 包基础：_test.go 文件约定、testing.T 的核心方法（t.Helper()、t.Cleanup()、t.Parallel()）、go test 的常用标志（-race、-cover、-run）。

表驱动测试：Go 社区的标准测试范式——将用例组织为 struct slice，用 t.Run 为每个用例创建子测试（独立命名、可并行）。新增用例只需在表中添加一行，边界条件一目了然。

testify：assert（失败继续）vs require（失败停止）的选择原则；ErrorIs/ErrorAs 断言与 Go 1.13 错误包装体系无缝集成。

Mock 策略：接口是 Mock 的基础——被测代码通过接口依赖外部服务，测试时注入 Mock 实现。手写 Mock 适合简单接口；gomock 通过代码生成处理复杂接口，提供期望次数验证、参数 Matcher、DoAndReturn 等强大功能。

CI 最佳实践：-race 标志在 CI 中始终开启；集成测试通过 build tags 或环境变量与单元测试隔离；覆盖率报告作为质量基线参考，不应追求 100%。

下一篇介绍 Go 性能剖析的完整工具集：05 Go 性能剖析——pprof、trace 与基准测试。

参考资料

Go 文档,《Testing》: https://pkg.go.dev/testing

Go Blog,《The Go Programming Language Specification - Testing》

testify: https://github.com/stretchr/testify

uber-go/mock (gomock): https://github.com/uber-go/mock

Go Blog,《Table-driven tests》

思考题

Go 的 interface 使得 Mock 变得简单——只需实现相同的 interface 即可替换依赖。但如果被测函数直接调用了 time.Now() 或 os.ReadFile() 这类标准库函数（不通过 interface），你有哪些方式使其可测试？每种方式的侵入性和工程成本如何？

表驱动测试（Table-Driven Test）是 Go 社区的标准实践。但当测试用例超过 50 个、且每个用例需要不同的 Mock 配置时，表驱动测试会变得难以维护。在什么情况下应该放弃表驱动测试，改用独立的子测试函数？Go 的 t.Run 嵌套有层数限制吗？

go test -race 使用 ThreadSanitizer 检测数据竞争。它的原理是在每次内存访问时插入检测代码。在一个包含大量 goroutine 的并发测试中，-race 会导致多大的性能开销（内存和 CPU）？如果 -race 没有报告任何竞争，能否保证代码一定没有数据竞争？为什么？

汀的知识碎片

文章导航

04 Go 测试体系——单元测试、表驱动测试与 Mock

Go 测试体系——单元测试、表驱动测试与 Mock

摘要

第 1 章 Go 测试基础：testing 包与 go test

1.1 测试文件的约定

1.2 testing.T 的核心方法

1.3 go test 常用标志

第 2 章表驱动测试：Go 的测试范式

2.1 什么是表驱动测试，为什么是 Go 的标准范式

2.2 t.Run 子测试：独立命名与并行化

2.3 测试夹具（Test Fixtures）

第 3 章 testify：流畅的断言库

3.1 为什么需要 testify

3.2 testify 常用断言

第 4 章 Mock：依赖隔离的关键

4.1 为什么需要 Mock

4.2 手写 Mock：最简单的方式

4.3 gomock：代码生成的 Mock 框架

4.4 httptest：HTTP 集成测试

第 5 章测试覆盖率与 CI 集成

5.1 理解测试覆盖率

5.2 CI 中的测试最佳实践

5.3 集成测试的隔离策略

总结

On this page

Backlinks

汀的知识碎片

文章导航

04 Go 测试体系——单元测试、表驱动测试与 Mock

Go 测试体系——单元测试、表驱动测试与 Mock

摘要

第 1 章 Go 测试基础：testing 包与 go test

1.1 测试文件的约定

1.2 testing.T 的核心方法

1.3 go test 常用标志

第 2 章 表驱动测试：Go 的测试范式

2.1 什么是表驱动测试，为什么是 Go 的标准范式

2.2 t.Run 子测试：独立命名与并行化

2.3 测试夹具（Test Fixtures）

第 3 章 testify：流畅的断言库

3.1 为什么需要 testify

3.2 testify 常用断言

第 4 章 Mock：依赖隔离的关键

4.1 为什么需要 Mock

4.2 手写 Mock：最简单的方式

4.3 gomock：代码生成的 Mock 框架

4.4 httptest：HTTP 集成测试

第 5 章 测试覆盖率与 CI 集成

5.1 理解测试覆盖率

5.2 CI 中的测试最佳实践

5.3 集成测试的隔离策略

总结

On this page

Backlinks

第 2 章表驱动测试：Go 的测试范式

第 5 章测试覆盖率与 CI 集成