t.Run(“”, func(t *testing.T) {
res := Add(0, 1)
if res != 1 {
t.Errorf(“the result is %d instead of 1”, res)
}
})
}
执行结果:
% go test -v
=== RUN TestAdd
=== RUN TestAdd/test1
=== RUN TestAdd/#00
— PASS: TestAdd (0.00s)
— PASS: TestAdd/test1 (0.00s)
— PASS: TestAdd/#00 (0.00s)
PASS
ok code.byted.org/ek/demo_test/t02_subtest/subtest 0.007s
可以看到输出中会将测试按照嵌套的结构分类,子测试的嵌套没有层数限制,如果不写测试名的话,会自动按照顺序给予序号作为其测试名(例如上面的#00)
对 IDE(Goland)友好的子测试
有一种测试的写法是:
tcList := map[string][]int{
“t1”: {1, 2, 3},
“t2”: {4, 5, 9},
}
for name, tc := range tcList {
t.Run(name, func(t *testing.T) {
require.Equal(t, tc[2], Add(tc[0], tc[1]))
})
}
看上去没什么问题,然而有一个缺点是,这个测试对 IDE 并不友好:
我们无法在出错的时候对单个测试重新执行 所以推荐尽可能对每个 t.Run 都要独立书写,例如:
f := func(a, b, exp int) func(t *testing.T) {
return func(t *testing.T) {
require.Equal(t, exp, Add(a, b))
}
}
t.Run(“t1”, f(1, 2, 3))
t.Run(“t2”, f(4, 5, 9))
测试分包
我们上面的 add.go 和 add_test.go 文件都处于同一个目录下,顶部的 package 名称都是 add,那么在写测试的过程中,也可以为测试启用与非测试文件不同的包名,例如我们现在将测试文件的包名改为 add_test:
// add_test.go
package add_test
import (
“testing”
)
func TestAdd(t *testing.T) {
res := Add(1, 2)
if res != 3 {
t.Errorf(“the result is %d instead of 3”, res)
}
}
这个时候执行 go test 会发现
% go test
# code.byted.org/ek/demo_test/t03_diffpkg_test [code.byted.org/ek/demo_test/t03_diffpkg.test]
./add_test.go:9:9: undefined: Add
FAIL code.byted.org/ek/demo_test/t03_diffpkg [build failed]
由于包名变化了,我们无法再访问到 Add 函数,这个时候我们增加 import 即可:
// add_test.go
package add_test
import (
“testing”
. “code.byted.org/ek/demo_test/t03_diffpkg”
)
func TestAdd(t *testing.T) {
res := Add(1, 2)
if res != 3 {
t.Errorf(“the result is %d instead of 3”, res)
}
}
我们使用上面的方式来导入包内的函数即可。 但使用了这种方式后,将无法访问包内未导出的函数(以小写开头的)。
测试的工具库
github.com/stretchr/testify
我们可以使用强大的 testify 来方便我们写测试 例如上面的测试我们可以用这个库写成:
// add_test.go
package correct
import (
“testing”
“github.com/stretchr/testify/require”
)
func TestAdd(t *testing.T) {
res := Add(1, 2)
require.Equal(t, 3, res)
/*
must := require.New(t)
res := Add(1, 2)
must.Equal(3, res)
*/
}
如果执行失败,则会在命令行看到如下输出:
% go test
ok code.byted.org/ek/demo_test/t04_libraries/testify/correct 0.008s
— FAIL: TestAdd (0.00s)
add_test.go:12:
Error Trace: add_test.go:12
Error: Not equal:
expected: 3
actual : -1
Test: TestAdd
FAIL
FAIL code.byted.org/ek/demo_test/t04_libraries/testify/wrong 0.009s
FAIL
库提供了格式化的错误详情(堆栈、错误值、期望值等)来方便我们调试。
github.com/DATA-DOG/go-sqlmock
对于需要测试 sql 的地方可以使用 go-sqlmock 来测试
-
优点:不需要依赖数据库
-
缺点:脱离了数据库的具体实现,所以需要写比较复杂的测试代码
github.com/golang/mock
强大的对 interface 的 mock 库,例如我们要测试函数 ioutil.ReadAll
func ReadAll(r io.Reader) ([]byte, error)
我们 mock 一个 io.Reader
// package: 输出包名
// destination: 输出文件
// io: mock对象的包
// Reader: mock对象的interface名
mockgen -package gomock -destination mock_test.go io Reader
可以在目录下看到 mock_test.go 文件里,包含了一个 io.Reader 的 mock 实现 我们可以使用这个实现去测试 ioutil.Reader,例如
ctrl := gomock.NewController(t)
defer ctrl.Finish()
m := NewMockReader(ctrl)
m.EXPECT().Read(gomock.Any()).Return(0, errors.New(“error”))
_, err := ioutil.ReadAll(m)
require.Error(t, err)
net/http/httptest
通常我们测试服务端代码的时候,会先启动服务,再启动测试。官方的 httptest 包给我们提供了一种方便地启动一个服务实例来测试的方法。
其他
其他一些测试工具可以前往 awesome-go#testing 查找
- https://github.com/avelino/awesome-go#testing
如何写好测试
上面介绍了测试的基本工具和写法,我们已经完成了“必先利其器”,下面我们将介绍如何“善其事”。
并发测试
在平时,大家写服务的时候,基本都必须考虑并发,我们使用 IDE 测试的时候,IDE 默认情况下并不会主动测试并发状态,那么如何保证我们写出来的代码是并发安全的? 我们来举个例子,比如我们有个计数器,作用就是计数。
type Counter int32
func (c *Counter) Incr() {
*c++
}
很显然这个计数器在并发情况下是不安全的,那么我们如何写一个测试来做这个计数器的并发测试呢?
import (
“sync”
“testing”
“github.com/stretchr/testify/require”
)
func TestA_Incr(t *testing.T) {
var a Counter
eg := sync.WaitGroup{}
count := 10
eg.Add(count)
for i := 0; i < count; i++ {
go func() {
defer eg.Done()
a.Incr()
}()
}
eg.Wait()
require.Equal(t, count, int(a))
}
通过多次执行上面的测试,我们发现有些时候,测试的结果返回 OK,有些时候测试的结果返回 FAIL。也就是说,即便写了测试,有可能在某次测试中被标记为通过测试。那么有没有什么办法直接发现问题呢?答案就是在测试的时候增加-race 的 flag
-race 标志不适合 benchmark 测试
go test -race
这时候终端会输出:
WARNING: DATA RACE
Read at 0x00c00001ca50 by goroutine 9:
code.byted.org/ek/demo_test/t05_race/race.(*A).Incr()
/Users/bytedance/go/src/code.byted.org/ek/demo_test/t05_race/race/race.go:6 +0x6f
code.byted.org/ek/demo_test/t05_race/race.TestA_Incr.func1()
/Users/bytedance/go/src/code.byted.org/ek/demo_test/t05_race/race/race_test.go:18 +0x66
Previous write at 0x00c00001ca50 by goroutine 8:
code.byted.org/ek/demo_test/t05_race/race.(*A).Incr()
/Users/bytedance/go/src/code.byted.org/ek/demo_test/t05_race/race/race.go:6 +0x85
code.byted.org/ek/demo_test/t05_race/race.TestA_Incr.func1()
/Users/bytedance/go/src/code.byted.org/ek/demo_test/t05_race/race/race_test.go:18 +0x66
Goroutine 9 (running) created at:
code.byted.org/ek/demo_test/t05_race/race.TestA_Incr()
/Users/bytedance/go/src/code.byted.org/ek/demo_test/t05_race/race/race_test.go:16 +0xe4
testing.tRunner()
/usr/local/Cellar/go/1.15/libexec/src/testing/testing.go:1108 +0x202
Goroutine 8 (finished) created at:
code.byted.org/ek/demo_test/t05_race/race.TestA_Incr()
/Users/bytedance/go/src/code.byted.org/ek/demo_test/t05_race/race/race_test.go:16 +0xe4
testing.tRunner()
/usr/local/Cellar/go/1.15/libexec/src/testing/testing.go:1108 +0x202
go 主动提示,我们的代码中发现了竞争(race)态,这个时候我们就要去修复代码
type Counter int32
func (c *Counter) Incr() {
atomic.AddInt32((*int32)©, 1)
}
修复完成后再次伴随-race 进行测试,我们的测试成功通过!
Golang 原生的并发测试
golang 的测试类 testing.T 有一个方法 Parallel(),所有在测试中调用了该方法的都会被标记为并发,但是注意,如果需要使用并发测试的结果的话,必须在外层用一个额外的测试函数将其包住:
func TestA_Incr(t *testing.T) {
var a Counter
t.Run(“outer”, func(t *testing.T) {
for i := 0; i < 100; i++ {
t.Run(“inner”, func(t *testing.T) {
t.Parallel()
a.Incr()
})
}
})
t.Log(a)
}
如果没有第三行的 t.Run,那么 11 行的打印结果将不正确
Golang 的 testing.T 还有很多别的实用方法,大家可以自己去查看一下,这里不详细讨论
正确测试返回值
作为一个 gopher 平时要写大量的 if err != nil,那么在测试一个函数返回的 error 的时候,我们比如有下面的例子
type I interface {
Foo() error
}
func Bar(i1, i2 I) error {
i1.Foo()
return i2.Foo()
}
Bar 函数希望依次处理 i1 和 i2 两个输入,当遇到第一个错误就返回,于是我们写了一个看起来“正确”的测试
import (
“errors”
“testing”
“github.com/stretchr/testify/require”
)
type impl string
func (i impl) Foo() error {
return errors.New(string(i))
}
func TestBar(t *testing.T) {
i1 := impl(“i1”)
i2 := impl(“i2”)
err := Bar(i1, i2)
require.Error(t, err) // assert err != nil
}
这个测试结果“看起来”很完美,函数正确返回了一个错误。但是实际上我们知道这个函数的返回值是错误的,所以我们应当把测试稍作修改,将 error 当作一个返回值来校验起内容,而不是简单的判 nil 处理
func TestBarFixed(t *testing.T) {
i1 := impl(“i1”)
i2 := impl(“i2”)
err := Bar(i1, i2)
// 两种写法都可
require.Equal(t, errors.New(“i1”), err)
require.Equal(t, “i1”, err.Error())
}
这个时候我们就能发现到,代码中出现了错误,需要修复了。 同理可以应用到别的返回值,我们不应当仅仅做一些简单的判断,而应当尽可能做“精确值”的判断。
测试输入参数
上面我们讨论过了测试返回值,输入值同样需要测试,这一点我们主要结合 gomock 来说,举个例子我们的代码如下:
type I interface {
Foo(ctx context.Context, i int) (int, error)
}
type bar struct {
i I
}
func (b bar) Bar(ctx context.Context, i int) (int, error) {
i, err := b.i.Foo(context.Background(), i)
return i + 1, err
}
我们想要测试 bar 类是否正确在方法中调用了 Foo 方法 我们使用 gomock 来 mock 出我们想要的 I 接口的 mock 实现:
mockgen -package gomock -destination mock_test.go io Reader
接下来我们写了一个测试:
import (
“context”
“testing”
. “code.byted.org/ek/testutil/testcase”
“github.com/stretchr/testify/require”
)
func TestBar(t *testing.T) {
t.Run(“test”, TF(func(must *require.Assertions, tc *TC) {
impl := NewMockI(tc.GomockCtrl)
i := 10
j := 11
ctx := context.Background()
impl.EXPECT().Foo(ctx, i).
Return(j, nil)
b := bar{i: impl}
r, err := b.Bar(ctx, i)
must.NoError(err)
must.Equal(j+1, r)
}))
}
测试运行成功,但实际上我们看了代码发现,代码中的 context 并没有被正确的传递,那么我们应该怎么去正确测试出这个情况呢? 一种办法是写一个差不多的测试,测试中修改 context.Background()为别的 context:
t.Run(“correct”, TF(func(must *require.Assertions, tc *TC) {
impl := NewMockI(tc.GomockCtrl)
i := 10
j := 11
ctx := context.WithValue(context.TODO(), “k”, “v”)
impl.EXPECT().Foo(ctx, i).
Return(j, nil)
b := bar{i: impl}
r, err := b.Bar(ctx, i)
must.NoError(err)
must.Equal(j+1, r)
}))
另一种办法是加入随机测试要素。
为测试加入随机要素
同样是上面的测试,我们稍做修改
import (
“context”
“testing”
randTest “code.byted.org/ek/testutil/rand”
. “code.byted.org/ek/testutil/testcase”
“github.com/stretchr/testify/require”
)
t.Run(“correct”, TF(func(must *require.Assertions, tc *TC) {
impl := NewMockI(tc.GomockCtrl)
i := 10
j := 11
ctx := context.WithValue(context.TODO(), randTest.String(), randTest.String())
impl.EXPECT().Foo(ctx, i).
Return(j, nil)
b := bar{i: impl}
r, err := b.Bar(ctx, i)
must.NoError(err)
must.Equal(j+1, r)
}))
这样就可以很大程度上避免由于固定的测试变量,导致的一些边缘 case 容易被误测为正确,如果回到之前的 Add 函数的例子,可以写成
import (
“math/rand”
“testing”
“github.com/stretchr/testify/require”
)
func TestAdd(t *testing.T) {
a := rand.Int()
b := rand.Int()
res := Add(a, b)
require.Equal(t, a+b, res)
}
经过修改的入参
如果我们修改一下之前的 Bar 的例子
func (b bar) Bar(ctx context.Context, i int) (int, error) {
ctx = context.WithValue(ctx, “v”, i)
i, err := b.i.Foo(ctx, i)
return i + 1, err
}
函数基本相同,只是传递给 Foo 方法的 ctx 变成了一个子 context,这个时候之前的测试就无法正确执行了,那么如何来判断传递的 context 是最上层的 context 的一个子 context 呢?
通过手写实现判断
一个方法是在测试中,传递给 Bar 一个 context.WithValue,然后在 Foo 的实现中去判断收到的 context 是否带有特定的 kv
t.Run(“correct”, TF(func(must *require.Assertions, tc *TC) {
impl := NewMockI(tc.GomockCtrl)
i := 10
j := 11
k := randTest.String()
v := randTest.String()
ctx := context.WithValue(context.TODO(), k, v)
impl.EXPECT().Foo(gomock.Any(), i).
Do(func(ctx context.Context, i int) {
s, _ := ctx.Value(k).(string)
must.Equal(v, s)
}).
Return(j, nil)
b := bar{i: impl}
r, err := b.Bar(ctx, i)
must.NoError(err)
must.Equal(j+1, r)
}))
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数软件测试工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上软件测试开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注软件测试)
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
v := randTest.String()
ctx := context.WithValue(context.TODO(), k, v)
impl.EXPECT().Foo(gomock.Any(), i).
Do(func(ctx context.Context, i int) {
s, _ := ctx.Value(k).(string)
must.Equal(v, s)
}).
Return(j, nil)
b := bar{i: impl}
r, err := b.Bar(ctx, i)
must.NoError(err)
must.Equal(j+1, r)
}))
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数软件测试工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年软件测试全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
[外链图片转存中…(img-difi12U9-1712734843898)]
[外链图片转存中…(img-Ga0h3yeN-1712734843899)]
[外链图片转存中…(img-LmNnvPrF-1712734843899)]
[外链图片转存中…(img-jSqhcaxu-1712734843899)]
[外链图片转存中…(img-eE2tMrIi-1712734843900)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上软件测试开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注软件测试)
[外链图片转存中…(img-ofIVZIXT-1712734843900)]
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!