标签 Mock 下的文章

使用testify包辅助Go测试指南

本文永久链接 – https://tonybai.com/2023/07/16/the-guide-of-go-testing-with-testify-package

我虽然算不上Go标准库的“清教徒”,但在测试方面还多是基于标准库testing包以及go test框架的,除了需要mock的时候,基本上没有用过第三方的Go测试框架。我在《Go语言精进之路》一书中对Go测试组织的讲解也是基于Go testing包和go test框架的。

最近看Apache arrow代码,发现arrow的Go实现使用了testify项目组织和辅助测试:

// compute/vector_hash_test.go

func TestHashKernels(t *testing.T) {
    suite.Run(t, &PrimitiveHashKernelSuite[int8]{})
    suite.Run(t, &PrimitiveHashKernelSuite[uint8]{})
    suite.Run(t, &PrimitiveHashKernelSuite[int16]{})
    suite.Run(t, &PrimitiveHashKernelSuite[uint16]{})
    ... ...
}

type PrimitiveHashKernelSuite[T exec.IntTypes | exec.UintTypes | constraints.Float] struct {
    suite.Suite

    mem *memory.CheckedAllocator
    dt  arrow.DataType
}

func (ps *PrimitiveHashKernelSuite[T]) SetupSuite() {
    ps.dt = exec.GetDataType[T]()
}

func (ps *PrimitiveHashKernelSuite[T]) SetupTest() {
    ps.mem = memory.NewCheckedAllocator(memory.DefaultAllocator)
}

func (ps *PrimitiveHashKernelSuite[T]) TearDownTest() {
    ps.mem.AssertSize(ps.T(), 0)
}

func (ps *PrimitiveHashKernelSuite[T]) TestUnique() {
    ... ...
}

同期,我在grank.io上看到testify这个项目综合排名第一:

这说明testify项目在Go社区有着广泛的受众,testify为何能从众多go test第三方框架中脱颖而出?它有哪些与众不同的地方?如何更好地利用testify来辅助我们的Go测试?带着这些问题,我写下了这篇有关testify的文章,供大家参考。

1. testify简介

testify是一个用于Go语言的测试框架,与go testing包可以很好的融合在一起,并由go test驱动运行。testify提供的功能特性可以辅助Go开发人员更好地组织和更高效地编写测试用例,以保证软件的质量和可靠性。

testify能够得到社区的广泛接纳,与testify项目中包的简洁与独立的设计是密不可分的。下面是testify包的目录结构(去掉了用于生成代码的codegen和已经deprecated的http目录后):

$tree -F -L 1 testify |grep "/" |grep -v codegen|grep -v http
├── assert/
├── mock/
├── require/
└── suite/

关于Go项目代码布局设计的系统讲解,可以参见我的《Go语言第一课》专栏的第5讲。

包目录名直接反映了testify可以提供给Go开发者的功能特性:

  • assert和require:断言工具包,辅助做测试结果判定;
  • mock:辅助编写mock test的工具包;
  • suite:提供了suite这一层的测试组织结构。

下面我们就由浅入深的介绍testify的这几个重要的、可各自独立使用的包。我们先从使用门槛最低的assert包和require包开始,它们是一类的,这里放在一个章节中介绍。

2. assert和require包

我们在使用go testing包编写Go单元测试用例时,通常会用下面代码来判断目标函数执行结果是否符合预期:

func TestFoo(t *testing.T) {
    v := Foo(5, 6) // Foo为被测目标函数
    if v != expected {
        t.Errorf("want %d, actual %d\n", expected, v)
    }
}

这样,如果测试用例要判断的结果很多,那么测试代码中就会存在很多if xx != yy以及Errorf/Fatalf之类的代码。有过一些其他语言编程经验的童鞋此时此刻肯定会说:是时候上assert了! 不过很遗憾,Go标准库包括其实验库(exp)都没有提供带有assert断言机制的包。

注:Go标准库testing/quick包中提供的Check和CheckEqual并非assert,它们用于测试两个函数参数在相同输入的情况下是否有相同的输出。如果不同,则输出导致输出不同的输入。此外,该quick包已经frozen,不再接受新Feature。

testify为Go开发人员提供了assert包,为Go开发人员很大程度“解了近渴”。

assert包使用起来非常简单,下面是assert使用的常见场景示例:

// assert/assert_test.go

func Add(a, b int) int {
    return a + b
}

func TestAssert(t *testing.T) {
    // Equal断言
    assert.Equal(t, 4, Add(1, 3), "The result should be 4")

    sl1 := []int{1, 2, 3}
    sl2 := []int{1, 2, 3}
    sl3 := []int{2, 3, 4}
    assert.Equal(t, sl1, sl2, "sl1 should equal to sl2 ")

    p1 := &sl1
    p2 := &sl2
    assert.Equal(t, p1, p2, "the content which p1 point to should equal to which p2 point to")

    err := errors.New("demo error")
    assert.EqualError(t, err, "demo error")

    // assert.Exactly(t, int32(123), int64(123)) // failed! both type and value must be same

    // 布尔断言
    assert.True(t, 1+1 == 2, "1+1 == 2 should be true")
    assert.Contains(t, "Hello World", "World")
    assert.Contains(t, []string{"Hello", "World"}, "World")
    assert.Contains(t, map[string]string{"Hello": "World"}, "Hello")
    assert.ElementsMatch(t, []int{1, 3, 2, 3}, []int{1, 3, 3, 2})

    // 反向断言
    assert.NotEqual(t, 4, Add(2, 3), "The result should not be 4")
    assert.NotEqual(t, sl1, sl3, "sl1 should not equal to sl3 ")
    assert.False(t, 1+1 == 3, "1+1 == 3 should be false")
    assert.Never(t, func() bool { return false }, time.Second, 10*time.Millisecond) //1秒之内condition参数都不为true,每10毫秒检查一次
    assert.NotContains(t, "Hello World", "Go")
}

我们看到assert包提供了Equal类、布尔类、反向类断言,assert包提供的断言函数有几十种,这里无法一一枚举,选择最适合你的测试场景的断言就好。

另外要注意的是,在Equal对切片作比较时,比较的是切片底层数组存储的内容是否相等;对指针作比较时,比较的是指针指向的内存块儿的数据是否相等,而不是指针本身的值是否相等。

注:assert.Equal底层实现使用的是reflect.DeepEqual。

我们看到assert包提供的断言函数第一个参数是testing.T的实例,如果一个测试用例里多次使用assert包的断言函数,我们每次都要传入testing.T的实例,比如下面示例:

// assert/assert_test.go

func TestAdd1(t *testing.T) {
    result := Add(1, 3)
    assert.Equal(t, 4, result, "The result should be 4")
    result = Add(2, 2)
    assert.Equal(t, 4, result, "The result should be 4")
    result = Add(2, 3)
    assert.Equal(t, 5, result, "The result should be 5")
    result = Add(0, 3)
    assert.Equal(t, 3, result, "The result should be 3")
    result = Add(-1, 1)
    assert.Equal(t, 0, result, "The result should be 0")
}

这很verbose! assert包提供了替代方法,如下面示例:

// assert/assert_test.go

func TestAdd2(t *testing.T) {
    assert := assert.New(t)

    result := Add(1, 3)
    assert.Equal(4, result, "The result should be 4")
    result = Add(2, 2)
    assert.Equal(4, result, "The result should be 4")
    result = Add(2, 3)
    assert.Equal(5, result, "The result should be 5")
    result = Add(0, 3)
    assert.Equal(3, result, "The result should be 3")
    result = Add(-1, 1)
    assert.Equal(0, result, "The result should be 0")
}

注:我们当然可以使用表驱动测试的方法将上述示例做进一步优化。

require包可以理解为assert包的“姊妹包”,require包实现了assert包提供的所有导出的断言函数,因此我们将上述示例中的assert改为require后,代码可以正常编译和运行(见require/require_test.go)。

那么require包与assert包有什么不同呢?我们来简单看一下。

使用assert包的断言时,如果某一个断言失败,该失败不会影响到后续测试代码的执行,或者说后续测试代码会继续执行,比如我们故意将TestAssert中的一些断言条件改为失败:

// assert/assert_test.go

    assert.True(t, 1+1 == 3, "1+1 == 2 should be true")
    assert.Contains(t, "Hello World", "World1")

再运行assert_test.go中的测试,我们会看到下面结果:

$go test
--- FAIL: TestAssert (1.00s)
    assert_test.go:34:
            Error Trace:
            Error:          Should be true
            Test:           TestAssert
            Messages:       1+1 == 2 should be true
    assert_test.go:35:
            Error Trace:
            Error:          "Hello World" does not contain "World1"
            Test:           TestAssert
FAIL
exit status 1
FAIL    demo    1.016s

我们看到:两个失败的测试断言都输出了!

我们再换到require/require_test.go下做同样的修改,并执行go test,我们得到如下结果:

$go test require_test.go
--- FAIL: TestRequire (0.00s)
    require_test.go:34:
            Error Trace:
            Error:          Should be true
            Test:           TestRequire
            Messages:       1+1 == 2 should be true
FAIL
FAIL    command-line-arguments  0.012s
FAIL

我们看到当执行完第一条失败的断言后,测试便结束了!

这就是assert包和require包的区别!这有些类似于Errorf和Fatalf的区别!require包中断言函数一旦执行失败便会导致测试退出,后续的测试代码将无法继续执行。

另外require包还有一个“特点”,那就是它的主体代码(require.go和require_forward.go)都是自动生成的:

// github.com/stretchr/testify/require/reqire.go
/*
  CODE GENERATED AUTOMATICALLY WITH github.com/stretchr/testify/_codegen
* THIS FILE MUST NOT BE EDITED BY HAND
 */

testify的代码生成采用了基于模板的方法,具体的自动生成原理可以参考[《A case for Go code generation: testify》] (https://levelup.gitconnected.com/a-case-for-go-code-generation-testify-73a4b0d46cb1)这篇文章。

3. suite包

Go testing包没有引入testsuite(测试套件)或testcase(测试用例)的概念,只有Test和SubTest。对于熟悉xUnit那套测试组织方式的开发者来说,这种缺失很“别扭”!要么自己基于testing包来构建这种结构,要么使用第三方包的实现。


该图来自网络

testify的suite包为我们提供了一种基于suite/case结构组织测试代码的方式。下面是一个可以对testify suite定义的suite结构进行全面解析的示例(改编自testify suite包文档中的ExampleTestSuite示例):

// suite/suite_test.go

package main

import (
    "fmt"
    "testing"

    "github.com/stretchr/testify/suite"
)

type ExampleSuite struct {
    suite.Suite
    indent int
}

func (suite *ExampleSuite) indents() (result string) {
    for i := 0; i < suite.indent; i++ {
        result += "----"
    }
    return
}

func (suite *ExampleSuite) SetupSuite() {
    fmt.Println("Suite setup")
}

func (suite *ExampleSuite) TearDownSuite() {
    fmt.Println("Suite teardown")
}

func (suite *ExampleSuite) SetupTest() {
    suite.indent++
    fmt.Println(suite.indents(), "Test setup")
}

func (suite *ExampleSuite) TearDownTest() {
    fmt.Println(suite.indents(), "Test teardown")
    suite.indent--
}

func (suite *ExampleSuite) BeforeTest(suiteName, testName string) {
    suite.indent++
    fmt.Printf("%sBefore %s.%s\n", suite.indents(), suiteName, testName)
}

func (suite *ExampleSuite) AfterTest(suiteName, testName string) {
    fmt.Printf("%sAfter %s.%s\n", suite.indents(), suiteName, testName)
    suite.indent--
}

func (suite *ExampleSuite) SetupSubTest() {
    suite.indent++
    fmt.Println(suite.indents(), "SubTest setup")
}

func (suite *ExampleSuite) TearDownSubTest() {
    fmt.Println(suite.indents(), "SubTest teardown")
    suite.indent--
}

func (suite *ExampleSuite) TestCase1() {
    suite.indent++
    defer func() {
        fmt.Println(suite.indents(), "End TestCase1")
        suite.indent--
    }()

    fmt.Println(suite.indents(), "Begin TestCase1")

    suite.Run("case1-subtest1", func() {
        suite.indent++
        fmt.Println(suite.indents(), "Begin TestCase1.Subtest1")
        fmt.Println(suite.indents(), "End TestCase1.Subtest1")
        suite.indent--
    })
    suite.Run("case1-subtest2", func() {
        suite.indent++
        fmt.Println(suite.indents(), "Begin TestCase1.Subtest2")
        fmt.Println(suite.indents(), "End TestCase1.Subtest2")
        suite.indent--
    })
}

func (suite *ExampleSuite) TestCase2() {
    suite.indent++
    defer func() {
        fmt.Println(suite.indents(), "End TestCase2")
        suite.indent--
    }()
    fmt.Println(suite.indents(), "Begin TestCase2")

    suite.Run("case2-subtest1", func() {
        suite.indent++
        fmt.Println(suite.indents(), "Begin TestCase2.Subtest1")
        fmt.Println(suite.indents(), "End TestCase2.Subtest1")
        suite.indent--
    })
}

func TestExampleSuite(t *testing.T) {
    suite.Run(t, new(ExampleSuite))
}

要知道testify.suite包定义的测试结构是什么样的,我们运行一下上述代码即可:

$go test
Suite setup
---- Test setup
--------Before ExampleSuite.TestCase1
------------ Begin TestCase1
---------------- SubTest setup
-------------------- Begin TestCase1.Subtest1
-------------------- End TestCase1.Subtest1
---------------- SubTest teardown
---------------- SubTest setup
-------------------- Begin TestCase1.Subtest2
-------------------- End TestCase1.Subtest2
---------------- SubTest teardown
------------ End TestCase1
--------After ExampleSuite.TestCase1
---- Test teardown
---- Test setup
--------Before ExampleSuite.TestCase2
------------ Begin TestCase2
---------------- SubTest setup
-------------------- Begin TestCase2.Subtest1
-------------------- End TestCase2.Subtest1
---------------- SubTest teardown
------------ End TestCase2
--------After ExampleSuite.TestCase2
---- Test teardown
Suite teardown

信息量很大,我们慢慢说!

利用testify建立测试套件,我们需要自行定义嵌入了suite.Suite的结构体类型,如上面示例中的ExampleSuite。

testify与go testing兼容,由go test驱动执行,因此我们需要在一个TestXXX函数中创建ExampleSuite的实例,调用suite包的Run函数,并将执行权交给suite包的这个Run函数,后续的执行逻辑就是suite包Run函数的执行逻辑。在上述代码中,我们只定义了一个TestXXX,并使用suite.Run函数执行了ExampleSuite中的所有测试用例。

suite.Run函数的执行逻辑大致是:通过反射机制得到了*ExampleSuite类型的方法集合,并执行方法集合中名字以Test为前缀的所有方法。testify将用户自定义的XXXSuite类型中的每个以Test为前缀的方法当作是一个TestCase。

除了Suite和TestCase的概念外,testify.suite包还“预埋”了很多回调点,包括suite的Setup、TearDown;test case的Setup和TearDown、testcase的before和after;subtest的Setup和TearDown,这些回调点也由suite.Run函数来执行,回调点的执行顺序可以通过上面示例的执行结果看到。

注意:subtest要通过XXXSuite的Run方法执行,而不要通过标准库testing.T的Run方法执行。

我们知道:go test工具可以通过-run命令行参数来选择要执行的TestXXX函数,考虑到testify使用TestXXX函数拉起测试套件(XXXSuite),因此从testify视角来看,通过go test -run可以选择执行哪个XXXSuite,前提是一个TestXXX中仅初始化和运行一种XXXSuite的所有测试用例。

如果要选择XXXSuite的方法(即testify眼中的测试用例),我们不能用-run了,需要使用testify新增的-m命令行选项,下面是一个仅执行带有Case2关键字测试用例的示例:

$go test -testify.m Case2
Suite setup
---- Test setup
--------Before ExampleSuite.TestCase2
------------ Begin TestCase2
---------------- SubTest setup
-------------------- Begin TestCase2.Subtest1
-------------------- End TestCase2.Subtest1
---------------- SubTest teardown
------------ End TestCase2
--------After ExampleSuite.TestCase2
---- Test teardown
Suite teardown
PASS
ok      demo    0.014s

综上,如果你使用testify的Suite/Case概念来组织你的测试代码,建议在每个TestXXX中仅初始化和运行一个XXXSuite,这样你可以通过-run选择特定的Suite执行。

4. mock包

最后我们来看看testify为辅助Go开发人员编写测试代码而提供的一个高级特性:mock。

在之前的文章中,我提到过:尽量使用fake object,而不是mock object。mock这种测试替身有其难于理解、使用场合局限以及给予开发人员信心不足等弊端。

注:近期原Go官方维护的golang/mock也将维护权迁移给了uber,迁移后的新的mock库为go.uber.org/mock。我在《Go语言精进之路 vol2》一书中对golang/mock做过详细的使用介绍,有兴趣的朋友可以去读一读。

但“存在即合理”,显然mock也有它的用武空间,在社区也有它的拥趸,既然testify提供了mock包,这里就简单介绍一下它的基本使用方法。

我们用一个经典repo service的例子来演示如何使用testify mock,如下面代码示例:

// mock/mock_test.go

type User struct {
    ID   int
    Name string
    Age  int
}

type UserRepository interface {
    CreateUser(user *User) (int, error)
    GetUserById(id int) (*User, error)
}

type UserService struct {
    repo UserRepository
}

func NewUserService(repo UserRepository) *UserService {
    return &UserService{repo: repo}
}

func (s *UserService) CreateUser(name string, age int) (*User, error) {
    user := &User{Name: name, Age: age}
    id, err := s.repo.CreateUser(user)
    if err != nil {
        return nil, err
    }
    user.ID = id
    return user, nil
}

func (s *UserService) GetUserById(id int) (*User, error) {
    return s.repo.GetUserById(id)
}

我们要提供一个UserService服务,通过该服务可以创建User,也可以通过ID获取User信息。服务的背后是一个UserRepository,你可以用任何方法实现UserRepository,为此我们将其抽象为一个接口UserRepository。UserService要依赖UserRepository才能让它的两个方法CreateUser和GetUserById正常工作。现在我们要测试UserService的这两个方法,但我们手里没有现成的UserRepository实现可用,我们也没有UserRepository的fake object。

这时我们仅能用mock。下面是使用testify mock给出的UserRepository接口的实现UserRepositoryMock:

// mock/mock_test.go

type UserRepositoryMock struct {
    mock.Mock
}

func (m *UserRepositoryMock) CreateUser(user *User) (int, error) {
    args := m.Called(user)
    return args.Int(0), args.Error(1)
}

func (m *UserRepositoryMock) GetUserById(id int) (*User, error) {
    args := m.Called(id)
    return args.Get(0).(*User), args.Error(1)
}

我们基于mock.Mock创建一个新结构体类型UserRepositoryMock,这就是我们要创建的模拟UserRepository。我们实现了它的两个方法,与正常方法实现不同的是,在方法中我们使用的是mock.Mock提供的方法Called以及它的返回值来满足CreateUser和GetUserById两个方法的参数与返回值要求。

UserRepositoryMock这两个方法的实现是比较“模式化”的,其中调用的Called接收了外部方法的所有参数,然后通过Called的返回值args来构造满足外部方法的返回值。返回值构造的书写格式如下:

args.<ReturnValueType>(<index>) // 其中index从0开始

以CreateUser为例,它有两个返回值int和error,那按照上面的书写格式,我们的返回值就应该为:args.int(0)和args.Error(1)。

对于复杂结构的返回值类型T,可使用断言方式,书写格式变为:

args.Get(index).(T)

再以构造GetUserById的返回值*User和error为例,我们按照复杂返回值构造的书写格式来编写,返回值就应该为args.Get(0).(*User)和args.Error(1)。

有了Mock后的UserRepository,我们就可以来编写UserService的方法的测试用例了:

// mock/mock_test.go

func TestUserService_CreateUser(t *testing.T) {
    repo := new(UserRepositoryMock)
    service := NewUserService(repo)

    user := &User{Name: "Alice", Age: 30}
    repo.On("CreateUser", user).Return(1, nil)

    createdUser, err := service.CreateUser(user.Name, user.Age)

    assert.NoError(t, err)
    assert.Equal(t, 1, createdUser.ID)
    assert.Equal(t, "Alice", createdUser.Name)
    assert.Equal(t, 30, createdUser.Age)

    repo.AssertExpectations(t)
}

func TestUserService_GetUserById(t *testing.T) {
    repo := new(UserRepositoryMock)
    service := NewUserService(repo)

    user := &User{ID: 1, Name: "Alice", Age: 30}
    repo.On("GetUserById", 1).Return(user, nil)

    foundUser, err := service.GetUserById(1)

    assert.NoError(t, err)
    assert.Equal(t, 1, foundUser.ID)
    assert.Equal(t, "Alice", foundUser.Name)
    assert.Equal(t, 30, foundUser.Age)

    repo.AssertExpectations(t)
}

这两个TestXXX函数的编写模式也十分相近,以TestUserService_GetUserById为例,它先创建了UserRepositoryMock和UserService的实例,然后利用UserRepositoryMock来设置即将被调用的GetUserById方法的输入参数与返回值:

user := &User{ID: 1, Name: "Alice", Age: 30}
repo.On("GetUserById", 1).Return(user, nil)

这样当GetUserById在service.GetUserById方法中被调用时,它返回的就是上面设置的user地址值和nil。

之后,我们像常规测试用例那样,用assert包对返回的值与预期值做断言即可。

5. 小结

在本文中,我们讲解了testify这个第三方辅助测试包的结构,并针对其中的assert/require、suite和mock这几个相对独立的Go包的用法做了重点说明。

assert/require包是功能十分全面的测试断言包,即便你不使用suite、mock,你也可以单独使用assert/require包来减少你的测试代码中if != xxx的书写行数。

suite包则为我们提供了一个类xUnit的Suite/Case的测试代码组织形式的实现方案,并且这种方案与go testing包兼容,由go test驱动。

虽然我不建议用mock,但testify mock也实现了mock机制的基本功能。并且文中没有提及的是,结合mockery工具和testify mock,我们可以针对接口为被测目标自动生成testify的mock部分代码,这会大大提交mock test的编写效率。

综上来看,testify这个项目的确非常有用,可以很好的辅助Go开发者高效的编写和组织测试用例。目前testify正在策划dev v2版本 ,相信不久将来落地的v2版本能给Go开发者带来更多的帮助。

本文涉及到的源码可以在这里下载。


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

单测时尽量用fake object

本文永久链接 – https://tonybai.com/2023/04/20/provide-fake-object-for-external-collaborators

1. 单元测试的难点:外部协作者(external collaborators)的存在

单元测试是软件开发的一个重要部分,它有助于在开发周期的早期发现错误,帮助开发人员增加对生产代码正常工作的信心,同时也有助于改善代码设计。Go语言从诞生那天起就内置Testing框架(以及测试覆盖率计算工具),基于该框架,Gopher们可以非常方便地为自己设计实现的package编写测试代码。

注:《Go语言精进之路》vol2中的第40条到第44条有关于Go包内、包外测试区别、测试代码组织、表驱动测试、管理外部测试数据等内容的系统地讲解,感兴趣的童鞋可以读读。

不过即便如此,在实际开发工作中,大家发现单元测试的覆盖率依旧很低,究其原因,排除那些对测试代码不作要求的组织,剩下的无非就是代码设计不佳,使得代码不易测;或是代码有外部协作者(比如数据库、redis、其他服务等)。代码不易测可以通过重构来改善,但如果代码有外部协作者,我们该如何对代码进行测试呢,这也是各种编程语言实施单元测试的一大共同难点

为此,《xUnit Test Patterns : Refactoring Test Code》一书中提供了Test Double(测试替身)的概念专为解决此难题。那么什么是Test Double呢?我们接下来就来简单介绍一下Test Double的概念以及常见的种类。

2. 什么是Test Double?

测试替身是在测试阶段用来替代被测系统依赖的真实组件的对象或程序(如下图),以方便测试,这些真实组件或程序即是外部协作者(external collaborators)。这些外部协作者在测试环境下通常很难获取或与之交互。测试替身可以使开发人员或QA专业人员专注于新的代码而不是代码与环境集成。

测试替身是通用术语,指的是不同类型的替换对象或程序。目前xUnit Patterns至少定义了五种类型的Test Doubles:

  • Test stubs
  • Mock objects
  • Test spies
  • Fake objects
  • Dummy objects

这其中最为常用的是Fake objects、stub和mock objects。下面逐一说说这三种test double:

2.1 fake object

fake object最容易理解,它是被测系统SUT(System Under Test)依赖的外部协作者的“替身”,和真实的外部协作者相比,fake object外部行为表现与真实组件几乎是一致的,但更简单也更易于使用,实现更轻量,仅用于满足测试需求即可。

fake object也是Go testing中最为常用的一类fake object。以Go的标准库为例,我们在src/database/sql下面就看到了Go标准库为进行sql包测试而实现的一个database driver:

// $GOROOT/src/database/fakedb_test.go

var fdriver driver.Driver = &fakeDriver{}

func init() {
    Register("test", fdriver)
}

我们知道一个真实的sql数据库的代码量可是数以百万计的,这里不可能实现一个生产级的真实SQL数据库,从fakedb_test.go源文件的注释我们也可以看到,这个fakeDriver仅仅是用于testing,它是一个实现了driver.Driver接口的、支持少数几个DDL(create)、DML(insert)和DQL(selet)的toy版的纯内存数据库:

// fakeDriver is a fake database that implements Go's driver.Driver
// interface, just for testing.
//
// It speaks a query language that's semantically similar to but
// syntactically different and simpler than SQL.  The syntax is as
// follows:
//
//  WIPE
//  CREATE|<tablename>|<col>=<type>,<col>=<type>,...
//    where types are: "string", [u]int{8,16,32,64}, "bool"
//  INSERT|<tablename>|col=val,col2=val2,col3=?
//  SELECT|<tablename>|projectcol1,projectcol2|filtercol=?,filtercol2=?
//  SELECT|<tablename>|projectcol1,projectcol2|filtercol=?param1,filtercol2=?param2

与此类似的,Go标准库中还有net/dnsclient_unix_test.go中的fakeDNSServer等。此外,Go标准库中一些以mock做前缀命名的变量、类型等其实质上是fake object。

我们再来看第二种test double: stub。

2.2 stub

stub显然也是一个在测试阶段专用的、用来替代真实外部协作者与SUT进行交互的对象。与fake object稍有不同的是,stub是一个内置了预期值/响应值且可以在多个测试间复用的替身object。

stub可以理解为一种fake object的特例。

注:fakeDriver在sql_test.go中的不同测试场景中时而是fake object,时而是stub(见sql_test.go中的newTestDBConnector函数)。

Go标准库中的net/http/httptest就是一个提供创建stub的典型的测试辅助包,十分适合对http.Handler进行测试,这样我们无需真正启动一个http server。下面就是基于httptest的一个测试例子:

// 被测对象 client.go

package main

import (
    "bytes"
    "net/http"
)

// Function that uses the client to make a request and parse the response
func GetResponse(client *http.Client, url string) (string, error) {
    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return "", err
    }

    resp, err := client.Do(req)
    if err != nil {
        return "", err
    }
    defer resp.Body.Close()

    buf := new(bytes.Buffer)
    _, err = buf.ReadFrom(resp.Body)
    if err != nil {
        return "", err
    }

    return buf.String(), nil
}

// 测试代码 client_test.go

package main

import (
    "net/http"
    "net/http/httptest"
    "testing"
)

func TestClient(t *testing.T) {
    // Create a new test server with a handler that returns a specific response
    server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusOK)
        w.Write([]byte(`{"message": "Hello, world!"}`))
    }))
    defer server.Close()

    // Create a new client that uses the test server
    client := server.Client()

    // Call the function that uses the client
    message, err := GetResponse(client, server.URL)

    // Check that the response is correct
    expected := `{"message": "Hello, world!"}`
    if message != expected {
        t.Errorf("Expected response %q, but got %q", expected, message)
    }

    // Check that no errors were returned
    if err != nil {
        t.Errorf("Unexpected error: %v", err)
    }
}

在这个例子中,我们要测试一个名为GetResponse的函数,该函数通过client向url发送Get请求,并将收到的响应内容读取出来并返回。为了测试这个函数,我们需要“建立”一个与GetResponse进行协作的外部http server,这里我们使用的就是httptest包。我们通过httptest.NewServer建立这个server,该server预置了一个返回特定响应的HTTP handler。我们通过该server得到client和对应的url参数后,将其传给被测目标GetResponse,并将其返回的结果与预期作比较来完成这个测试。注意,我们在测试结束后使用defer server.Close()来关闭测试服务器,以确保该服务器不会在测试结束后继续运行。

httptest还常用来做http.Handler的测试,比如下面这个例子:

// handler.go

package main

import (
    "bytes"
    "io"
    "net/http"
)

func AddHelloPrefix(w http.ResponseWriter, r *http.Request) {
    b, err := io.ReadAll(r.Body)
    if err != nil {
        w.WriteHeader(http.StatusBadRequest)
        return
    }
    w.Write(bytes.Join([][]byte{[]byte("hello, "), b}, nil))
    w.WriteHeader(http.StatusOK)
}

// handler_test.go

package main

import (
    "net/http"
    "net/http/httptest"
    "strings"
    "testing"
)

func TestHandler(t *testing.T) {
    r := strings.NewReader("world!")
    req, err := http.NewRequest("GET", "/test", r)
    if err != nil {
        t.Fatal(err)
    }

    rr := httptest.NewRecorder()
    handler := http.HandlerFunc(AddHelloPrefix)
    handler.ServeHTTP(rr, req)

    if status := rr.Code; status != http.StatusOK {
        t.Errorf("handler returned wrong status code: got %v want %v",
            status, http.StatusOK)
    }

    expected := "hello, world!"
    if rr.Body.String() != expected {
        t.Errorf("handler returned unexpected body: got %v want %v",
            rr.Body.String(), expected)
    }
}

在这个例子中,我们创建一个新的http.Request对象,用于向/test路径发出GET请求。然后我们创建一个新的httptest.ResponseRecorder对象来捕获服务器的响应。 我们定义一个简单的HTTP Handler(被测函数): AddHelloPrefix,该Handler会在请求的内容之前加上”hello, “并返回200 OK状态代码作为响应体。之后,我们在handler上调用ServeHTTP方法,传入httptest.ResponseRecorder和http.Request对象,这会将请求“发送”到处理程序并捕获响应。最后,我们使用标准的Go测试包来检查响应是否具有预期的状态码和正文。

在这个例子中,我们利用net/http/httptest创建了一个测试服务器“替身”,并向其“发送”间接预置信息的请求以测试Go中的HTTP handler。这个过程中其实并没有任何网络通信,也没有http协议打包和解包的过程,我们也不关心http通信,那是Go net/http包的事情,我们只care我们的Handler是否能按逻辑运行。

fake object与stub的优缺点基本一样。多数情况下,大家也无需将这二者划分的很清晰

2.3 mock object

和fake/stub一样,mock object也是一个测试替身。通过上面的例子我们看到fake建立困难(比如创建一个近2千行代码的fakeDriver),但使用简单。而mock object则是一种建立简单,使用简单程度因被测目标与外部协作者交互复杂程度而异的test double,我们看一下下面这个例子:

// db.go 被测目标

package main

// Define the `Database` interface
type Database interface {
    Save(data string) error
    Get(id int) (string, error)
}

// Example functions that use the `Database` interface
func saveData(db Database, data string) error {
    return db.Save(data)
}

func getData(db Database, id int) (string, error) {
    return db.Get(id)
}

// 测试代码

package main

import (
    "testing"

    "github.com/stretchr/testify/assert"
    "github.com/stretchr/testify/mock"
)

// Define a mock struct that implements the `Database` interface
type MockDatabase struct {
    mock.Mock
}

func (m *MockDatabase) Save(data string) error {
    args := m.Called(data)
    return args.Error(0)
}

func (m *MockDatabase) Get(id int) (string, error) {
    args := m.Called(id)
    return args.String(0), args.Error(1)
}

func TestSaveData(t *testing.T) {
    // Create a new mock database
    db := new(MockDatabase)

    // Expect the `Save` method to be called with "test data"
    db.On("Save", "test data").Return(nil)

    // Call the code that uses the database
    err := saveData(db, "test data")

    // Assert that the `Save` method was called with the correct argument
    db.AssertCalled(t, "Save", "test data")

    // Assert that no errors were returned
    assert.NoError(t, err)
}

func TestGetData(t *testing.T) {
    // Create a new mock database
    db := new(MockDatabase)

    // Expect the `Get` method to be called with ID 123 and return "test data"
    db.On("Get", 123).Return("test data", nil)

    // Call the code that uses the database
    data, err := getData(db, 123)

    // Assert that the `Get` method was called with the correct argument
    db.AssertCalled(t, "Get", 123)

    // Assert that the correct data was returned
    assert.Equal(t, "test data", data)

    // Assert that no errors were returned
    assert.NoError(t, err)
}

在这个例子中,被测目标是两个接受Database接口类型参数的函数:saveData和getData。显然在单元测试阶段,我们不能真正为这两个函数传入真实的Database实例去测试。

这里,我们没有使用fake object,而是定义了一个mock object:MockDatabase,该类型实现了Database接口。然后我们定义了两个测试函数,TestSaveData和TestGetData,它们分别使用MockDatabase实例来测试saveData和getData函数。

在每个测试函数中,我们对MockDatabase实例进行设置,包括期待特定参数的方法调用,然后调用使用该数据库的代码(即被测目标函数saveData和getData)。然后我们使用github.com/stretchr/testify中的assert包,对代码的预期行为进行断言。

注:除了上述测试中使用的AssertCalled方法外,MockDatabase结构还提供了其他方法来断言方法被调用的次数、方法被调用的顺序等。请查看github.com/stretchr/testify/mock包的文档,了解更多信息。

3. Test Double有多种,选哪个呢?

从mock object的例子来看,测试代码的核心就是mock object的构建与mock object的方法的参数和返回结果的设置,相较于fake object的简单直接,mock object在使用上较为难于理解。而且对Go语言来说,mock object要与接口类型联合使用,如果被测目标的参数是非接口类型,mock object便“无从下嘴”了。此外,mock object使用难易程度与被测目标与外部协作者的交互复杂度相关。像上面这个例子,建立mock object就比较简单。但对于一些复杂的函数,当存在多个外部协作者且与每个协作者都有多次交互的情况下,建立和设置mock object就将变得困难并更加难于理解。

mock object仅是满足了被测目标对依赖的外部协作者的调用需求,比如设置不同参数传入下的不同返回值,但mock object并未真实处理被测目标传入的参数,这会降低测试的可信度以及开发人员对代码正确性的信心。

此外,如果被测函数的输入输出未发生变化,但内部逻辑发生了变化,比如调用的外部协作者的方法参数、调用次数等,使用mock object的测试代码也需要一并更新维护。

而通过上面的fakeDriver、fakeDNSSever以及httptest应用的例子,我们看到:作为test double,fake object/stub有如下优点:

  • 我们与fake object的交互方式与与真实外部协作者交互的方式相同,这让其显得更简单,更容易使用,也降低了测试的复杂性;
  • fake objet的行为更像真正的协作者,可以给开发人员更多的信心;
  • 当真实协作者更新时,我们不需要更新使用fake object时设置的expection和结果验证条件,因此,使用fake object时,重构代码往往比使用其他test double更容易。

不过fake object也有自己的不足之处,比如:

  • fake object的创建和维护可能很费时,就像上面的fakeDriver,源码有近2k行;
  • fake object可能无法提供与真实组件相同的功能覆盖水平,这与fake object的提供方式有关。
  • fake object的实现需要维护,每当真正的协作者更新时,都必须更新fake object。

综上,测试的主要意义是保证SUT代码的正确性,让开发人员对自己编写的代码更有信心,从这个角度来看,我们在单测时应首选为外部协作者提供fake object以满足测试需要

4. fake object的实现和获取方法

随着技术的进步,fake object的实现和获取日益容易。

我们可以借助类似ChatGPT/copilot的工具快速构建出一个fake object,即便是几百行代码的fake object的实现也很容易。

如果要更高的可信度和更高的功能覆盖水平,我们还可以借助docker来构建“真实版/无阉割版”的fake object。

借助github上开源的testcontainers-go可以更为简便的构建出一个fake object,并且testcontainer提供了常见的外部协作者的封装实现,比如:MySQL、Redis、Postgres等。

以测试redis client为例,我们使用testcontainer建立如下测试代码:

// redis_test.go

package main

import (
    "context"
    "fmt"
    "testing"

    "github.com/go-redis/redis/v8"
    "github.com/testcontainers/testcontainers-go"
    "github.com/testcontainers/testcontainers-go/wait"
)

func TestRedisClient(t *testing.T) {
    // Create a Redis container with a random port and wait for it to start
    req := testcontainers.ContainerRequest{
        Image:        "redis:latest",
        ExposedPorts: []string{"6379/tcp"},
        WaitingFor:   wait.ForLog("Ready to accept connections"),
    }
    ctx := context.Background()
    redisC, err := testcontainers.GenericContainer(ctx, testcontainers.GenericContainerRequest{
        ContainerRequest: req,
        Started:          true,
    })
    if err != nil {
        t.Fatalf("Failed to start Redis container: %v", err)
    }
    defer redisC.Terminate(ctx)

    // Get the Redis container's host and port
    redisHost, err := redisC.Host(ctx)
    if err != nil {
        t.Fatalf("Failed to get Redis container's host: %v", err)
    }
    redisPort, err := redisC.MappedPort(ctx, "6379/tcp")
    if err != nil {
        t.Fatalf("Failed to get Redis container's port: %v", err)
    }

    // Create a Redis client and perform some operations
    client := redis.NewClient(&redis.Options{
        Addr: fmt.Sprintf("%s:%s", redisHost, redisPort.Port()),
    })
    defer client.Close()

    err = client.Set(ctx, "key", "value", 0).Err()
    if err != nil {
        t.Fatalf("Failed to set key: %v", err)
    }

    val, err := client.Get(ctx, "key").Result()
    if err != nil {
        t.Fatalf("Failed to get key: %v", err)
    }

    if val != "value" {
        t.Errorf("Expected value %q, but got %q", "value", val)
    }
}

运行该测试将看到类似如下结果:

$go test
2023/04/15 16:18:20 github.com/testcontainers/testcontainers-go - Connected to docker:
  Server Version: 20.10.8
  API Version: 1.41
  Operating System: Ubuntu 20.04.3 LTS
  Total Memory: 10632 MB
2023/04/15 16:18:21 Failed to get image auth for docker.io. Setting empty credentials for the image: docker.io/testcontainers/ryuk:0.3.4. Error is:credentials not found in native keychain

2023/04/15 16:19:06 Starting container id: 0d8341b2270e image: docker.io/testcontainers/ryuk:0.3.4
2023/04/15 16:19:10 Waiting for container id 0d8341b2270e image: docker.io/testcontainers/ryuk:0.3.4
2023/04/15 16:19:10 Container is ready id: 0d8341b2270e image: docker.io/testcontainers/ryuk:0.3.4
2023/04/15 16:19:28 Starting container id: 999cf02b5a82 image: redis:latest
2023/04/15 16:19:30 Waiting for container id 999cf02b5a82 image: redis:latest
2023/04/15 16:19:30 Container is ready id: 999cf02b5a82 image: redis:latest
PASS
ok      demo    73.262s

我们看到建立这种真实版的“fake object”的一大不足就是依赖网络下载container image且耗时过长,在单元测试阶段使用还是要谨慎一些。testcontainer更多也会被用在集成测试或冒烟测试上。

一些开源项目,比如etcd,也提供了用于测试的自身简化版的实现(embed)。这一点也值得我们效仿,在团队内部每个服务的开发者如果都能提供一个服务的简化版实现,那么对于该服务调用者来说,它的单测就会变得十分容易。

5. 参考资料

  • 《xUnit Test Patterns : Refactoring Test Code》- https://book.douban.com/subject/1859393/
  • Test Double Patterns – http://xunitpatterns.com/Test%20Double%20Patterns.html
  • The Unit in Unit Testing – https://www.infoq.com/articles/unit-testing-approach/
  • Test Doubles — Fakes, Mocks and Stubs – https://blog.pragmatists.com/test-doubles-fakes-mocks-and-stubs-1a7491dfa3da

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats