- 端到端测试：正如Martin Fowler 所说 大量的端到端测试增加了测试时间，并且使得测试成本变得昂贵。
-
单元测试: 执行更加迅速，维护成本更低，因此单元测试的积累是我们走向卓越工程的必须项,单元测试的执行也使得测试粒度更细，能够更轻易发现我们代码中的缺陷。
以上每一条都阐述了单元测试的必要性，在各大顶尖互联网公司中，均认为单元测试是必要且收益较高的，因此在一个卓越工程下研发同学是一定需要写单元测试的。
|
|
|
|
|
-
各个应用维护自己的单元测试的脚本，定制化太强，不规范，难以维护。
|
-
将各个应用的单元测试脚本集成为Aone实验室插件，提供通用化的执行脚本，极大降低接入成本，用户无需维护臃肿的单脚本。
|
|
|
-
提供固定机器，每次执行如果释放测试资源不及时，导致机器性能低下，磁盘占用过高。
|
-
将单元测试集成为插件形式，通过即插即用的容器化资源，每次执行单元测试后释放测试资源，降低维护成本。
|
|
|
-
-
在覆盖率的采集上，无法指定过滤那些文件不进行统计覆盖率；
-
单测指令的优化，需要修改所有应用的脚本，这使得每一次的迭代成本都极大。
|
-
-
在覆盖率采集中，支持ignore忽略统计的选项支持；
-
在执行单元测试上，通过优化gc，修改cpu执行参数，并优化了单元测试的执行路径，使得单测执行速度有了更大的提升。
|
|
|
-
在覆盖率采集中，使用go-cov和diff-cover这两个组件生成增量覆盖率和行覆盖率，会缺少没有写单测的包下所有文件，未执行的业务代码也不会进行统计，导致整体的覆盖率计算都是不精确的。
|
-
中，通过对增量覆盖率的实现进行重写，基于git diff 的结果和覆盖率文件进行重新计算增量代码的覆盖情况，产出准确的增量覆盖率；
-
行覆盖率则使用go原生ast解析生成所有文件的函数代码行，解决行覆盖率统计不准问题。
|
|
|
-
对于单测执行，测试报告内容以及覆盖率展示比较简单，用户无法清晰看出测试问题。
|
-
在的实现中，将整体的测试报告进行了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单测插件，填写当前项目的单测命令即可。
