研发:就不能不写单测吗?
- 端到端测试:正如Martin Fowler 所说 大量的端到端测试增加了测试时间,并且使得测试成本变得昂贵。
- 单元测试: 执行更加迅速,维护成本更低,因此单元测试的积累是我们走向卓越工程的必须项,单元测试的执行也使得测试粒度更细,能够更轻易发现我们代码中的缺陷。
以上每一条都阐述了单元测试的必要性,在各大顶尖互联网公司中,均认为单元测试是必要且收益较高的,因此在一个卓越工程下研发同学是一定需要写单元测试的。
Golang单元测试的整体思路和实践
当前实现方式对比2.0单元测试实现上的优化点
单元测试2.0 | 单元测试3.0 | |
接入成本 |
|
|
测试资源问题 |
|
|
各个应用执行单测差异性 |
|
|
覆盖率采集不准 |
|
|
报告展示 |
|
|
从golang单测的插件说起:
插件的整体架构:
在整个CI流程中,我们依赖aone实验室提供的action工作流,实现了golang的单元测试的插件,在插件中我们分别去执行go的单测,全量覆盖率的扫描,增量覆盖率的扫描,分支覆盖率的扫描。
基于go语言的编译特性,我们将go服务编译为一个个的二进制文件,在bash环境中执行每一个任务并获取最终结果。
插件的代码结构如下:
aone-golang-ut-plugin |--main // 主入口文件 |--bootstrap.sh // 插件执行依赖环境安装 go&python3 |--execute.sh // 主执行文件 |--log.sh // 日志文件 |--config.yml //插件接入核心.yml文件 |--util.sh // shell工具类 |--init.sh // 初始化项目 |--bin //插件执行依赖bin文件 |-gocov |-diff-cover |-go-branch-cov
插件执行时序图:
go单元测试的执行
目前go的单元测试是直接使用go官方的单测cli命令执行,可参考[1]。
单测命令示例:
go test ./... -timeout 3m -v -gcflags=-l \ -cover=true -coverprofile=$coverFile -coverpkg=./... -mod=vendor
我们在go项目根目录下执行这条单测命令就可以运行go项目的单元测试并产出覆盖率文件,并根据单测命令中给出的flag标记,例如cover,coverprofile 等就可以产出单测的覆盖率信息。
在使用过程中,我们可以直接使用插件,在插件中自定义当前项目的单测命令,例如:
这样就能轻松的在持续集成过程中运行我们的单测了。
实践效果和接入
实验室执行结果:
测试报告的查看:
单元测试执行结果的报告:其中包含单测函数的执行结果,单测执行的详情,分支覆盖率的详情。
行增量覆盖率的报告:
目前已累计接入应用50+
如何接入使用?
最简单的接入方式,实现最强大的功能。在实验室中选择高德golang单测插件,填写当前项目的单测命令即可。参考链接:[1]https://pkg.go.dev/cmd/go#hdr-Testing_flags
作者 | 陈敏锐(姜依)
来源 | 阿里云开发者公众号