技术博客
首页 所有文章 标签 分类 关于
技术博客

目录

2025-01-09-golang单元测试及mock总结

 收录于 Golang
   约 3945 字   预计阅读 8 分钟 
https://bing.ee123.net/img/rand?artid=131742158

golang单元测试及mock总结

文章目录

一、前言

1、单测的定位

单测在软件工程中的地位毋庸置疑，它要求工程师必须去主动思考代码的边界，异常处理等等。另一方面，它又是代码最好的说明书，你的函数具体做了什么，输入和输出一目了然。

计算机科学家Edsger Dijkstra曾说过：“测试能证明缺陷存在，而无法证明没有缺陷。”再多的测试也不能证明一个程序没有BUG。在最好的情况下，测试可以增强我们的信心：代码在很多重要场景下是可以正常工作的。

参考：

2、vscode中生成单测

参考：

vscode 生成单元测试如下，我们需要编写测试用例数组，明确指出来want结果以及wantErr,通过遍历的方式去执行测试用例数组。

func TestGenerateStsTokenService(t *testing.T) {
	type args struct {
		ctx             context.Context
		generateStsData *dto.GenerateStsReqParams
	}
	tests := []struct {
		name     string
		args     args
		wantResp *common.RESTResp
		wantErr  bool
	}{
		{
			name: "测试正常生成sts",
			args: args{
				ctx: context.TODO(),
				generateStsData: &dto.GenerateStsReqParams{
					SessionName: "webApp",
					AuthParams:  &dto.AuthParamsData{},
				},
			},
			wantResp: &common.RESTResp{
				Code: 0,
				Data: &dto.OssStsRespData{
				},
			},
			wantErr: false,
		},
		{
			name: "测试异常生成sts",
			args: args{
				ctx: context.TODO(),
				generateStsData: &dto.GenerateStsReqParams{
					SessionName: "liteApp",
					AuthParams:  &dto.AuthParamsData{},
				},
			},
			wantResp: &common.RESTResp{
				Code: 20003,
				Data: interface{}(nil),
			},
			wantErr: true,
		},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
 
			gotResp, err := GenerateStsTokenService(tt.args.ctx, tt.args.generateStsData)
			if (err != nil) != tt.wantErr {
				t.Errorf("GenerateStsTokenService() error = %v, wantErr %v", err, tt.wantErr)
				return
			}
			if !reflect.DeepEqual(gotResp, tt.wantResp) {
				t.Errorf("GenerateStsTokenService() = %v, want %v", gotResp, tt.wantResp)
			}
		})
	}
}

二、构造测试case的注意事项

1、项目初始化

// TestMain会在执行其他测试用例的时候，自动执行
func TestMain(m *testing.M) {
    setup()  //初始化函数
    retCode := m.Run() // 运行单元测试
    teardown() //后置校验，钩子函数，可不实现
    os.Exit(retCode) //清理结果
}

2、构造空interface

// 直接给Data赋值为nil的话，验证会失败，
// 单纯的nil和(*infra.QueryOneMappingCode)(nil)是不一样的
wantResp: &common.RESTResp{
				Code:    0,
				Message: "",
				Data:    (*infra.QueryOneMappingCode)(nil),
			},

// 数组类型的空
// []dto.OneMappingCode{}也会验证失败
wantRes: []dto.OneMappingCode(nil),

3、构造结构体的time.Time类型

Data: &infra.xxx{
					ID:          54,
					Code:        "338798",
					TakerUid:    "",
					State:       1,
					Type:        1,
					CreatedAt: time.Date(2023, time.June, 9, 16, 32, 59, 0, time.Local),
				},

也可以直接打印接口的返回，看看CreatedAt返回的是什么，然后构造一下就可以。
t.Logf("gotResp:(%#v)", gotResp.Data)

4、构造json格式的test case

wantResp: &common.RESTResp{
				Code:    0,
				Message: "success",
				Data: `{
					"id": 54,
					"code": "338798",
					"creator_uid": "12345",
					"client_appId": "1234",
					"taker_uid": "",
					"state": 1,
					"type": 1,
					"created_at": "2023-06-09T16:32:59+08:00"
				   }`,
			},

三、运行单测文件

1、整体运行单测文件

  cd /xxx 单测目录
  go test
  成功输出：
  PASS
  ok

2、运行单个单测文件报错

错误提示如下：

# command-line-arguments [command-line-arguments.test]
./base_test.go:26:18: undefined: Ping

明明 Ping 函数和单测文件都在同一个包下面，为什么会出现 undefined 呢？ command-line-arguments 是什么？

答：

（1）command-line-arguments是什么
go test [flags] [packages] [build flags] [packages]
命令行参数中指定的每个包或文件都将被视为一个要进行测试的包。而 "command-line-arguments" 
这个标识符就是用来表示上述情况中命令行参数中指定的文件。

这样可以使 go test 命令将指定的文件作为单独的包进行处理，并执行其中的测试函数。
（2）undefined发生原因

错误提示build失败，也就是说我们需要把单测文件依赖的文件也传入进去。比如我这里单测base_test.go文件，则需要把base.go也写到命令行参数中。

具体参考：

go test ./base.go ./base_test.go
（3）缺少初始化导致的发生panic

一般来说我们在一个package下，定义一个TestMain()函数就可以了，进行代码的初始化。但是当我们需要运行单个测试文件的时候，有可能这个测试文件里面恰好没有TestMain()了咋整。

api_test.go
	TestMain()
base_test.go // 没有TestMain()函数

// 解决方案
1、初始化代码放到setup()函数中
2、go命令行
go test ./base.go ./base_test.go ./api_test.go ./api.go
3、只想运行base_test.go怎么办
	base_test.go中加上自己的setuoBase()

3、查看单测覆盖率

go test -cover
	coverage: 80.4% of statements

4、单测覆盖文件解读

go test -coverprofile=coverage.out

// 打开单测覆盖率文件
mode: set
base.go:10.118,14.23 3 1
base.go:14.23,17.3 2 1

	解释如下：
	10.118,14.23 3 1 表示第 10 行到第 14 行代码被测试覆盖到了，且覆盖
	率为 3/1 (即 300%)。这是因为第 10 行至少执行了一次，如果执行了三次，则覆盖率为 300%。
	14.23,17.3 2 1 表示第 14 行到第 17 行代码被测试覆盖到了，且覆盖率为 2/1 (即 200%)。

5、生成可被浏览器打开的单测文件

go test -coverprofile=coverage.out
go tool cover -html=coverage.out -o coverage.html

绿色代表被覆盖到的代码，红色代表没有被覆盖到的代码。

左上角是运行单测命令目录下，所有go文件的覆盖率。

可以考虑新增单测case来覆盖到这部分红色。

https://i-blog.csdnimg.cn/blog_migrate/27237e079e641c9187d16384adf25a3f.png

6、单测覆盖率的问题

覆盖率为 100% 表示测试用例覆盖了所有的可能执行路径，即程序的所有功能都被覆盖到了。而覆盖率高于 100% 则表示相同的代码路径被多次测试或某些代码行在被测试期间被执行了多次。

但是单测 100%并 不能保证没有 bug ，只能保证写出来的代码没问题，但逻辑或者业务上的漏洞是检测不到的。

博主在滴滴的组是建议单测覆盖率 50% 以上，其他朋友的公司要求核心接口必须有单测，整体单测覆盖率 30% 以上。有需要的可以参考下。

四、关于单测粒度的问题

写单测的时候，总会疑问到底要写的多细呢？特别是原来项目没有单测的时候，补单测的代码比业务逻辑代码还多。。。

本例中，目录结构如下：

domain:
	base.go
	code.go
	code_test.go
	util.go

code.go 会调用 base.go 和 util.go 的函数，运行 code_test.go 发现单测覆盖率

已经 80% 了，是不是意味着只需要写个 code_test.go 就可以了呢？

1、chatgpt的回答

实际上不是的， base.go 和 util.go 后续还可能被其他的文件使用，我们写单测的时候，应该尽量覆盖所有的异常情况，也就是程序的边界问题。因此 base.go 和 util.go 也需要做对应的单测，这样才能得到高质量的代码。

2、个人理解

单个 code_test.go 文件导致的问题是下层函数不 mock ，可能会影响到实际的数据，导致单测只能运行一次，而不能一直 PASS 。其次是代码流程变长导致单测 case 越写越多，接近集成测试了，这不是我们单测的目标。

把 code_test.go 中关于 base.go 和 util.go 的函数都给 mock 掉，发现单测覆盖率只有 37% ，且测试路径比较短。还需要分别写 base_test.go 和util_test.go，写完 util_test.go 单测覆盖率立马 82% 。

拆分的粒度变细，更加关注每个函数的输入和输出。特别是当修改某个函数的时候，只需要使用对应的单测来进行验证，而不需要从入口处进行测试。毕竟单元测试不是集成测试。

参考：

五、mock数据

在写单测的时候，程序难免会出现各种跨文件的函数调用，以及操作第三方中间件或者上下游交互的情况，这个时候 mock 就显得尤为重要。

想象下，没有 mock 的时候，我们运行单测可能就会写入一次数据库？或者对下游发起一次请求？这样的单测，怕是只能运行一次哟。 mock 的出现让我们关注代码的实现细节，不会担心会造成数据污染或者单测只能运行一遍就GG的情况。

1、mock组件选择

参考：

https://i-blog.csdnimg.cn/blog_migrate/9dc60b91d817769520660f1e64868193.png

博主这里更喜欢无侵入的 mock ，直接一把梭。可惜 monkey 已经不更新了，现在都是用 gomonkey ,国人大佬开发的

2、mock实操

（1）mock函数调用

函数中存在大量的封装调用，比如 A->B ， A->C 这种，因此自由 mock B 和 C 函数对我们的单元测试来说还是很重要的。

patches := gomonkey.ApplyFunc(queryOneMappCode, func(ctx context.Context, code string) (*infra.QueryOneMappingCode, error) {
				// 参数大于6则返回空
				if len(code) > 6 {
					return nil, nil
				}
				return &infra.QueryOneMappingCode{
					ID:          54,
					Code:        "338798",
					CreatedAt:   time.Date(2023, time.June, 9, 16, 32, 59, 0, time.Local),
				}, nil
			})
			defer patches.Reset()
（2）mock方法调用
1、实例化接口
var mockProvider = provider.Test
// 接口如下
type TestDbProvider interface {
	SetDb(db *sqlx.DB)
	GetOne(dest interface{}, sql string, args interface{}) (resp *infra.QueryOneMappingCode, err error)
}


2、mock对应的查询方法
// 注意，第一个参数不能是指针，不然mock会失效
// 例如 var oss_bucket_obj *oss.Bucket ，传入target为: *oss_bucket_obj
// 传地址会报错
patches := gomonkey.ApplyMethodFunc(mockProvider, "GetOne", func(dest interface{}, sql string, args interface{}) (resp *infra.QueryOneMappingCode, err error) {
				code := args.(string)
				if code == "123456" {
					return &infra.QueryOneMappingCode{
						ID:          1,
						Code:        "123456",
						CreatedAt:   time.Date(2023, time.June, 9, 16, 32, 59, 0, time.Local),
					}, nil
				} else if code == "456789" {
					return &infra.QueryOneMappingCode{
						ID:          1,
						Code:        "456789",
						CreatedAt:   time.Date(2023, time.June, 9, 16, 32, 59, 0, time.Local),
					}, nil
				} else {
					return nil, nil
				}
			})
			defer patches.Reset()
（3）mock其他包的函数

在 xx_test 文件中直接引用其他包即可。一般 xx_test.go 和 xx.go 在同一个包下，所以也不用担心出现循环引用的问题。

patches := gomonkey.ApplyFunc(util.GenerateRandomCode, func(numDigits int) string {
				return "123456"
			})
			defer patches.Reset()
（4）mock循环中的函数

比如在A函数中，循环3次调用了B函数，那么mock如下：

createA := &infra.CreateMappingCode{Code: "933903"}
			createB := &infra.CreateMappingCode{Code: "601690"}
			createC := &infra.CreateMappingCode{Code: "798493"}
			p := gomonkey.ApplyFuncSeq(structureMappingCodeRecord, []gomonkey.OutputCell{
				{Values: gomonkey.Params{createA}},
				{Values: gomonkey.Params{createB}},
				{Values: gomonkey.Params{createC}},
			})
			defer p.Reset() // 恢复原始函数
（5）mock http调用
// vscode自动生成的test代码
for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			// mock httptest
			ts := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
				if r.Method != http.MethodGet {
					w.WriteHeader(http.StatusNotFound)
				}
				// 构造返回参数
				w.WriteHeader(http.StatusOK)
				// 获取POST请求的参数，根据参数返回不同的响应
				bodyBytes, err := io.ReadAll(r.Body)
				if err != nil {
					// 处理错误
					w.WriteHeader(http.StatusBadRequest)
				}
				// 获取post参数
				params := new(dto.GenerateStsReqParams)
				json.Unmarshal(bodyBytes, params)
				// 根据传递的参数返回不同的响应
				res := new(common.RESTResp)
				if params.SessionName == "webApp" {
					res = &common.RESTResp{
						Code:    0,
						Message: "success",
						Data: &dto.OssStsRespData{
							Region:          "hangzhou",
							Bucket:          "test",
						},
					}
				} else {
					res = &common.RESTResp{
						Code:    1,
						Message: "failed",
						Data:    &dto.OssStsRespData{},
					}
				}
				// 模拟接口的返回，http接口返回是字节数据，因此需要json.Marshal
				jsonStr, _ := json.Marshal(res)
				w.Write(jsonStr)
			}))
			defer ts.Close()
			// 替换原来的url为mock的url
			GenerateOssStsUrl = ts.URL
    	// 发起请求，请求中的http会被mock掉
			gotResp, err := GenerateStsTokenService(tt.args.ctx, tt.args.generateStsData)
			if (err != nil) != tt.wantErr {
				t.Errorf("GenerateStsTokenService() error = %v, wantErr %v", err, tt.wantErr)
				return
			}
			t.Logf("gotResp:(%#v) ,wantResp:(%#v)", gotResp, tt.wantResp)
			if !reflect.DeepEqual(gotResp, tt.wantResp) {
				t.Errorf("GenerateStsTokenService() = %v, want %v", gotResp, tt.wantResp)
			}
		})
	}

3、对于mock的看法

对于 mock ，有以下两种态度

一方的人主张不要滥用mock，能不mock就不mock。被测单元也不一定是具体的一个
函数，可能是多个函数本来就应该串起来，必要的时候再mock。

一方则主张将被测函数所有调用的外面函数全部mock掉，只关注被测函数自己的
一行行代码，只要调用其他函数，全都mock掉，用假数据来测试。

本来处于懒惰和少写单测的角度，我是支持第一种方式的。

例如：
单测函数：A函数
内部逻辑：
	A->B : B函数全是业务逻辑
	A->C : C函数包括mysql或者redis操作
	A->D->E: D函数纯业务逻辑，构造请求参数。E函数对外发起http请求

第一种方式是只 mock C 和 E 函数，测试 A 函数的时候，会把 B 和 D 也测试到。主打一个省事快捷。

直到我遇到了更复杂的场景， B 里面还有 B1 和 B2 函数， D 里面有 D1 和 D2 函数，逻辑非常复杂的情况下，第一种方式就变成了集成测试。单测用例慢慢变成了测试用例。 比如只修改 D2 函数的情况下，要修改和通过单测 A 进行测试。。。。

第二种方式，就是在每一层都 mock 掉外部调用。单测 A 就只关注 A 的逻辑， mock 掉 B,C,D,E ，只关注 B,C,D,E 输出是正确或者错误的情况。

针对 B,C,D,E 函数又有自己的单测函数，充分覆盖掉。这样当修改 D2 函数的时候，只需要修改和通过 D2 的单测即可。

对于外部依赖，比如第三方库 mysql,redis,mq 这种统一进行 mock 。 对于内部的函数调用，建议是粒度细一些， A_test.go 就只对 A.go 里面的逻辑负责。至于调用 B.go 的部分，就交给 B_test.go 吧。

end

68747470:733a2f2f626c6f672e6373646e2e6e65742f4c4a465048502f:61727469636c652f64657461696c732f313331373432313538

更新于 2025-01-09
 Golang, 单元测试, 开发语言
返回 | 主页