snowcrumble/golang单元测试实践.md

## golang单元测试实践.md

      
    Raw
  

              golang单元测试实践.md
            
          
    我的 golang 单元测试实践

本文不涉及 go 的单元测试的基本结构，以及为什么我们要写单元测试，和 TDD 的好处。简单是说就是 what why how 这里只提 how，而且是 how I did。
测试框架选择

无框架
或叫原生框架

table driven tests或叫控制反转
stretchr/testify 好用的 assert 工具

BDD 框架

ginkgo
goconvey

我个人喜欢无框架，我认为测试框架的核心价值在于 BDD 和可视化，BDD 让测试代码与业务逻辑紧密结合，非常适合敏捷开发。可视化让测试结果可以更直观，但本质上跟go test在控制台输出的内容和go tool cover -html=coverage.out输出的页面上的内容区别不大。
测试代码风格

控制反转, 是 go 官方推荐的测试风格，也是gotests工具默认模板的风格，由于我的开发工具 VSCode 中的 go 插件带的默认测试工具就是 gotests，所以下面以 gotests 为例，比如我有一个 MyService 类型，提供一个 Query 方法
// service.go
type MyService struct {
    rdsCli  *redis.Client
    db *gorm.DB
}

func (x * MyService) Query() (int, error) {
    return 0, nil
}
用 gotests 工具生成测试代码
gotests -w -all service.go
生成测试代码如下：
// service_test.go
func TestMyService_Query(t *testing.T) {
    type fields struct {
        rdsCli *redis.Client
        db     *gorm.DB
    }
    tests := []struct {
        name    string
        fields  fields
        want    int
        wantErr bool
    }{
        // TODO: Add test cases.
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            x := &MyService{
                rdsCli: tt.fields.rdsCli,
                db:     tt.fields.db,
            }
            got, err := x.Query()
            if (err != nil) != tt.wantErr {
                t.Errorf("MyService.Query() error = %v, wantErr %v", err, tt.wantErr)
                return
            }
            if !reflect.DeepEqual(got, tt.want) {
                t.Errorf("MyService.Query() = %v, want %v", got, tt.want)
            }
        })
    }
}
得益于控制反转，我只需要在 TODO 处添加一些sub test cases即可。
但是这个模板也有一些问题
构造冗余
比如每写一个sub test case，都需要填写构造 Service 的参数，这对于有状态的结构做了很好的隔离，每次测试都使用全新的 MyService。而通常我的 Service 是无状态的，大多数sub test case都可以使用同一个 Service 实例，这时每次都构造一遍就会产生冗余。假如我的 Service 会有一个构造方法 New：
func New(rdsCli *redis.Client, db *gorm.DB) *MyService {
	return & MyService{
		rdsCli: rdsCli,
		db: db,
	}
}
gotests 工具提供了自定义模板的功能，我可以把模板可以简化为：
// service_test.go
func TestMyService_Query(t *testing.T) {
    x := New(rdsCli, db)
    tests := []struct {
        name    string
        want    int
        wantErr bool
    }{
        // TODO: Add test cases.
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := x.Query()
            assert.Nil(t, err)
            assert.Equal(t, tt.want, got)
        })
    }
}
这里同时用 assert 包代替 go 原生丑陋的错误处理。
复杂的返回值校验
另外一个问题，对于待测试的方法的返回值，如果只检查其是否DeepEqual，有时候满足不了一些测试需求，当我无法预测返回值的所有字段的时候，比如有一个 Insert 方法，返回值中会带有我无法预测的 LastInsertId，或者一个依赖的其他包的接口，返回值包含一些不稳定字段。这时候有两个解决问题的方向

把所有不稳定的因素改为稳定因素——用 Mock
改变测试模板

第一种方式需要我们对 golang 的代码风格有一个较好的理解，才可以在做 Mock 时可以比较方便。
第一种的具体内容下面再说，我先说一下第二种，是比较简单直接的方式，可以把模板的校验返回值的部分也改为控制反转风格，比如：
// service_test.go
func TestMyService_Query(t *testing.T) {
    x := New(rdsCli, db)
    tests := []struct {
        name    string
        check   func(int, error)
    }{
        // TODO: Add test cases.
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            tt.check(x.Query())
        })
    }
}
每个sub test case的返回值由用户定义如何检测，发挥控制反转的最后余力。
外部依赖怎么 Mock

go 推崇 Interface，舍弃了继承，这突出了**正交(orthogonal)**的概念，隔壁 Rust 也是这样的理念。Interface 是写出 testable 代码的关键，比如依赖注入用 Interface 代替 struct。我举个例子，比如 MyService 依赖了 rand 包暴露的一个 RandSource 结构体和它的 Rand 方法，这个方法返回一个随机整数。
package rand

import "math/rand"

type RandSource struct{}

func New() *RandSource {
	return &RandSource{}
}

func (x *RandSource) Rand() int {
	return rand.Int()
}
Service 结构体依赖 RandSource 结构体
// service.go
type MyService struct {
    rs  *rand.RandSource
}

func (x * MyService) Query() (int, error) {
    return x.rs.Rand(), nil
}
这时在上面的测试代码中，我们没办法预测 Query 的返回值，这时我想到了写一个 MockRandSource 来代替 RandSource，返回一个稳定的整数。但由于 MyService 依赖的是 RandSource 结构体，go 语言又没有提供继承或者方法重载的语义，没法利用里氏替换原则，这时候 Interface 就派上用场了，我们把依赖由结构体改为 Interface
//定义内部Interface
type randSource interface {
    Rand() int
}

// service.go
type MyService struct {
    rs  randSource //依赖内部Interface
}

func (x * MyService) Query() (int, error) {
    return x.rs.Rand(), nil
}
这样我们就可以在测试代码里写一个 randSourceMock 了：
// service_test.go
type randSourceMock struct{}
func (randSourceMock) Rand() int {
    return 123
}
func TestMyService_Query(t *testing.T) {
    x := &randSource{
        rs: &randSourceMock{},
    }
    tests := []struct {
        name    string
        want    int
        wantErr bool
    }{
        {
            name:   "ok",
            want:   123,
        },
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := x.Query()
            assert.Nil(t, err)
            assert.Equal(t, tt.want, got)
        })
    }
}
这样，所有的外部依赖都可以用 Interface 来写出 testable 的代码了。对于这块的理解上其实有一个小技巧，就是尽可能的在你的包里用你自己定义的 Interface 做依赖注入
也可以用testify's mock提供的 Mock 机制做更灵活的 Mock
数据库相关的 CRUD 怎么测

Using External
CRUD 统统在一个测试方法内完成，C 为 RU 的基础，用 D 做资源回收。不过这就超出了单元测试的概念，偏向于集成测试，即你的程序与外部的数据库的集成。
也可以基于外部的临时容器，初始化一些必要测试数据
Mock SQL
CRUD 单独测试
go-sqlmock，完整稳定的实现了database/sql/driver，做到无数据库测试，符合 TDD 工作流。所有基于 go 标准库database/sql/driver的 orm 框架也都支持，以 GORM 为例，比如我有一个 Dao 包，提供一个 LastInertId 方法：
Mock Redis Server
miniredis 是一个实现了 Redis Server 的包，专门用于 Go 的单元测试，目前支持 Redis6 的几乎所有开发会用到的命令
Redis
package dao

type Dao struct {
    db   *gorm.DB
}

func New(db *gorm.DB) *Dao {
    return &Dao{
        db:   db,
    }
}

type intT struct{
    Uint1 uint64 `gorm:"column:uint1"`
}

//LastInsertId 获取最后一条插入语句生成的自增ID
func (x *Dao) LastInsertId() (uint64, error) {
    result := &intT{}
    if err := x.db.Raw("SELECT LAST_INSERT_ID() AS `uint1`").Scan(&result).Error; err != nil {
        return 0, err
    }
    return result.Uint1, nil
}
测试代码可以这么写：
//dao_test.go
func getMockDB(t *testing.T) (*gorm.DB, sqlmock.Sqlmock) {
    db, mock, err := sqlmock.New()
    assert.Nil(t, err)

    gdb, err := gorm.Open("mysql", db)
    assert.Nil(t, err)

    return gdb, mock
}

func TestDao_LastInsertId(t *testing.T) {
    db, mock := getMockDB(t)
    defer db.Close()
    x := New(db)

    tests := []struct {
        name    string
        want    uint64
        wantErr bool
    }{
        {
            name:    "ok",
            want:    123,
            wantErr: false,
        },
    }
    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            mock.ExpectQuery(regexp.QuoteMeta("SELECT LAST_INSERT_ID() AS `uint1`")).
                WillReturnRows(sqlmock.NewRows([]string{"uint1"}).
                    AddRow(123))
            got, err := x.LastInsertId(ctx)
            assert.Nil(t, err)
            assert.Equal(t, tt.want, got)
        })
    }
}
其他

HTTP
可以用 go 标准库的 httptest 包
gRPC
gRPC 生成的 client stub 都是 Interface，所以可以很方便的写 mock
总结

如果遵循上面提到的，控制反转测试风格，依赖注入接口，Mock。那么我们几乎就可以做到 Dave 在 2019 Gopher China 上分享《Testing; how, what, why》中提到的一个“信念”：

I hold it as an article of faith that writing tests at the same time as the code is a good thing.
一个戛然而止的收尾。