Code前端首页关于Code前端联系我们

在实践单元测试3.0中构建Golang的质量生态

terry 2年前 (2023-09-24) 阅读数 82 #后端开发

研发：为什么不写单元测试？

端到端测试：正如 Martin Fowler 所说，太多的端到端测试会增加测试时间并使测试成本高昂。
单元测试：执行速度更快，维护成本更低。因此，单元测试的积累是迁移到卓越项目的必要条件。单元测试的执行还提高了测试的粒度，使我们更容易发现代码中的缺陷。

上面的每一点都解释了单元测试的必要性。在顶级互联网公司中，单元测试被认为是必要且有利可图的。因此，卓越项目的研发学生必须编写单元测试。。 Golang单元测试的整体思路与实践当前实现方法对比以及单元测试实现中的优化点

	单元测试	单元测试
获取自己的申请费单元测试脚本有高度可定制、非标准且难以维护。	将各个应用的单元测试脚本接入Aone Lab插件，提供通用的脚本执行，降低访问成本，用户无需维护单个臃肿的脚本。
资源问题测试	机器保持供应。如果每次执行时没有及时释放测试资源，机器的性能会很低，磁盘使用率会很高。	将单元测试接入插件形式，利用即插即用的容器资源，在每次单元测试运行后释放测试资源，降低维护成本。
每个应用执行一次测试的差异	执行过程中无法确定Golang执行环境的版本；在覆盖率集合中，无法指定要过滤的文件而不统计覆盖率；测试指令的单一优化需要修改整个应用脚本，这使得每次迭代的成本都非常高。	支持多个Go可执行版本；覆盖率收集中，支持忽略选项忽略统计信息；在单元测试执行中，通过优化gc、改变cpu执行参数、优化单元测试执行线，提高单测试执行速度。
覆盖率收集不准确	在覆盖率收集中，使用go-cov和diff-cover两个组件来生成增量覆盖率和行覆盖率。包中所有未编写单个测试的文件都将丢失。，未执行的业务代码不会被统计在内，导致整体覆盖率计算不准确。	中，通过重写增量覆盖率实现，根据git diff结果和覆盖率文件重新计算增量代码覆盖率，产生准确的增量覆盖率；行覆盖率评估器使用Go原生解析为所有文件生成函数代码行，解决行覆盖率统计不准确的问题。
报告显示	对于单次测试执行来说，测试报告的内容和覆盖率显示都比较简单，用户无法清楚地看到测试问题。	实施中，将整体测试报告转为HTML，并更改页面，使报告的展示更加清晰；并获取准确的覆盖数据来定制一套报告显示方法。生成的报告更好、更清晰。？插件，在我们的插件中我们执行one 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单元测试c'正式执行。，请参见[1]。单个测试命令示例： `go test ./... -timeout 3m -v -gcflags=-l \` `-cover=true -coverprofile=$coverFile -coverpkg=./... -mod=vendor` 我们在go项目的根目录下运行这个单个测试命令来运行go项目的单元测试并生成覆盖率文件，并根据单个测试中给出的标志命令，例如 cover、coverprofile 等，可以从单个测试中生成覆盖率信息。在使用过程中，我们可以直接使用该插件，并在插件中管理当前项目的单元测试命令，例如：这样我们就可以在持续集成过程中轻松运行我们的单元测试过程。。？覆盖范围详细信息。报告额外线路覆盖：目前已接入50+应用如何接入使用？最简单的访问方法来获得最强大的功能。在实验室选择Amap golang单测插件，输入当前项目单测命令。

版权声明

本文仅代表作者观点，不代表Code前端网立场。
本文系作者Code前端网发表，如需转载，请注明页面地址。

上一篇：Django中url、path、re_path的区别下一篇：Django添加ckeditor富文本编辑器教程

发表评论:取消回复

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。