![]()
以上每一条都阐述了单元测试的必要性，在各大顶尖互联网公司中，均认为单元测试是必要且收益较高的，因此在一个卓越工程下研发同学是一定需要写单元测试的。
| | |
| - 各个应用维护自己的单元测试的脚本，定制化太强，不规范，难以维护。
| - 将各个应用的单元测试脚本集成为Aone实验室插件，提供通用化的执行脚本，极大降低接入成本，用户无需维护臃肿的单脚本。
|
| - 提供固定机器，每次执行如果释放测试资源不及时，导致机器性能低下，磁盘占用过高。
| - 将单元测试集成为插件形式，通过即插即用的容器化资源，每次执行单元测试后释放测试资源，降低维护成本。
|
| - 在覆盖率的采集上，无法指定过滤那些文件不进行统计覆盖率；
- 单测指令的优化，需要修改所有应用的脚本，这使得每一次的迭代成本都极大。
| - 在覆盖率采集中，支持ignore忽略统计的选项支持；
- 在执行单元测试上，通过优化gc，修改cpu执行参数，并优化了单元测试的执行路径，使得单测执行速度有了更大的提升。
|
| - 在覆盖率采集中，使用go-cov和diff-cover这两个组件生成增量覆盖率和行覆盖率，会缺少没有写单测的包下所有文件，未执行的业务代码也不会进行统计，导致整体的覆盖率计算都是不精确的。
| - 3.0中，通过对增量覆盖率的实现进行重写，基于git diff 的结果和覆盖率文件进行重新计算增量代码的覆盖情况，产出准确的增量覆盖率；
- 行覆盖率则使用go原生ast解析生成所有文件的函数代码行，解决行覆盖率统计不准问题。
|
| - 对于单测执行，测试报告内容以及覆盖率展示比较简单，用户无法清晰看出测试问题。
| - 在3.0的实现中，将整体的测试报告进行了html化，并进行页面美化，使得报告展示更明晰；
- 并接入准确的覆盖率数据自定义了一套展示报告的方式，生成的报告更加美观清晰。
|
![]()
在整个CI流程中，我们依赖aone实验室提供的action工作流，实现了golang的单元测试的插件，在插件中我们分别去执行go的单测，全量覆盖率的扫描，增量覆盖率的扫描，分支覆盖率的扫描。基于go语言的编译特性，我们将go服务编译为一个个的二进制文件，在bash环境中执行每一个任务并获取最终结果。aone-golang-ut-plugin |--main |--bootstrap.sh |--execute.sh |--log.sh |--config.yml |--util.sh |--init.sh |--bin |-gocov |-diff-cover |-go-branch-cov
![]()
目前go的单元测试是直接使用go官方的单测cli命令执行，可参考[1]。go test ./... -timeout 3m -v -gcflags=-l \ -cover=true -coverprofile=$coverFile -coverpkg=./... -mod=vendor
我们在go项目根目录下执行这条单测命令就可以运行go项目的单元测试并产出覆盖率文件，并根据单测命令中给出的flag标记，例如cover，coverprofile 等就可以产出单测的覆盖率信息。在使用过程中，我们可以直接使用插件，在插件中自定义当前项目的单测命令，例如：单元测试执行结果的报告：其中包含单测函数的执行结果，单测执行的详情，分支覆盖率的详情。在实验室中选择高德golang单测插件，填写当前项目的单测命令即可。[1]https://pkg.go.dev/cmd/go#hdr-Testing_flags
阿里云开发者社区，百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，欢迎点击【阅读原文】加入我们。