单元测试3.0实践之Golang质量生态建设

研发:就不能不写单测吗?

单元测试3.0实践之Golang质量生态建设_第1张图片

单元测试3.0实践之Golang质量生态建设_第2张图片

  • 端到端测试:正如Martin Fowler所说,大量的端到端测试增加了测试时间,并且使得测试成本变得昂贵。

  • 单元测试: 执行更加迅速,维护成本更低,因此单元测试的积累是我们走向卓越工程的必须项,单元测试的执行也使得测试粒度更细,能够更轻易发现我们代码中的缺陷。

以上每一条都阐述了单元测试的必要性,在各大顶尖互联网公司中,均认为单元测试是必要且收益较高的,因此,在卓越工程下研发同学是一定需要写单元测试的。

Golang单元测试的整体思路和实践

当前实现方式对比2.0单元测试实现上的优化点


单元测试2.0

单元测试3.0

接入成本

-各个应用维护自己的单元测试的脚本,定制化太强,不规范,难以维护。

-将各个应用的单元测试脚本集成为Aone实验室插件,提供通用化的执行脚本,极大降低接入成本,用户无需维护臃肿的单脚本。

测试资源问题

-提供固定机器,每次执行如果释放测试资源不及时,导致机器性能低下,磁盘占用过高。

-将单元测试集成为插件形式,通过即插即用的容器化资源,每次执行单元测试后释放测试资源,降低维护成本。

各个应用执行单测差异性

-在执行过程中无法指定Golang的执行环境版本;

-在覆盖率的采集上,无法指定过滤哪些文件不进行统计覆盖率;

-单测指令的优化,需要修改所有应用的脚本,这使得每一次的迭代成本都极大。

-支持所有Golang版本;

-覆盖率计算上支持忽略统计;

-在单元测试执行上支持跳过部分case的执行;

-在执行单元测试上,通过优化gc,修改cpu执行参数,并优化了单元测试的执行路径,使得单测执行速度有了更大的提升;

-支持单元测试检测数据竞争问题。

覆盖率采集不准

-在覆盖率采集中,使用go-cov和diff-cover这两个组件生成增量覆盖率和行覆盖率,会缺少没有写单测的包下所有文件,未执行的业务代码也不会进行统计,导致整体的覆盖率计算都是不精确的。

-3.0中,通过对增量覆盖率的实现进行重写,基于git diff 的结果和覆盖率文件进行重新计算增量代码的覆盖情况,产出准确的增量覆盖率;

-行覆盖率则使用go原生ast解析生成所有文件的函数代码行,解决行覆盖率统计不准问题。

报告展示

-对于单测执行,测试报告内容以及覆盖率展示比较简单,用户无法清晰看出测试问题。

-在3.0的实现中,将整体的测试报告进行了html化,并进行页面美化,使得报告展示更明晰;

-并接入准确的覆盖率数据自定义了一套展示报告的方式,生成的报告更加美观清晰。

从Golang单测的插件说起:

插件的整体架构:

单元测试3.0实践之Golang质量生态建设_第3张图片

在整个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文件


        |-go-coverage-engine   // 覆盖率计算引擎 


        |-go-ci-tools    // Go持续集成通用工具


        |-upload   // 测试报告上传组件

插件执行时序图:

单元测试3.0实践之Golang质量生态建设_第4张图片

Go单元测试的执行

目前Go的单元测试是直接使用Go官方的单测Cli命令执行,可参考Go官方资料。

单测命令示例:

go test ./... -timeout 3m -v -gcflags=-l \
       -cover=true -coverprofile=$coverFile -coverpkg=./... -mod=vendor

我们在Go项目根目录下执行这条单测命令就可以运行Go项目的单元测试并产出覆盖率文件,并根据单测命令中给出的Flag标记,例如Cover,Coverprofile等就可以产出单测的覆盖率信息。

在使用过程中,我们可以直接使用插件,在插件中自定义当前项目的单测命令,例如:

单元测试3.0实践之Golang质量生态建设_第5张图片

这样就能轻松的在持续集成过程中运行单测了。

实践效果和接入

实验室执行结果:

单元测试3.0实践之Golang质量生态建设_第6张图片

测试报告的查看:

单元测试执行结果的报告:其中包含单测函数的执行结果,单测执行的详情,分支覆盖率的详情。

单元测试3.0实践之Golang质量生态建设_第7张图片

行增量覆盖率的报告:

单元测试3.0实践之Golang质量生态建设_第8张图片

目前已累计接入应用50+ 

如何接入使用?

最简单的接入方式,实现最强大的功能。

在实验室中选择高德Golang单测插件,填写当前项目的单测命令即可。

参考链接:

[1]https://pkg.go.dev/cmd/go#hdr-Testing_flags

推荐阅读

  • 你是否思考过,学习会带来什么样的坏处?

  • 高德地图作业平台低代码实战

  • 我们是否对现代前端开发框架过于崇拜了?

  • 从业务开发中学习和理解架构设计

  • 从GFS到GPT,AI Infra的激荡20年

关注「高德技术」,了解更多

你可能感兴趣的:(单元测试,golang,junit,开发语言,后端)