[鸿蒙开发] 13 - 如何获取HarmonyOS应用的代码覆盖率信息

沉江小鱼
517 阅读8分钟

1. 背景

1.1 背景描述

目前在准备鸿蒙应用的开发环境，由于项目要求，需要在提交CodeReview的时候，展示单元测试的覆盖率。但是目前并没有针对于鸿蒙应用的打包流程，如果要等一切完善之后再开发，那时间可太长了，所以需要调研一种可行的短期的方案。

最终的目标是通过自动化的方式将代码覆盖率的数据以文本的方式（coverage： Line Coverage: 100%, Branch Coverage: 100%）添加到git commit的信息中，如下图所示：

企业微信截图_33282d79-8f88-414e-8cec-fb4f9c4c40fa.png

1.2 实施计划

先确定下大概的实施计划：

  • 调研如何构建HarmonyOS应用的单元测试和UI测试；
  • 获取测试覆盖率文件；
  • 如何通过命令构建HarmonyOS应用和执行HarmonyOS应用的单元测试和UI测试；
  • 通过脚本修改git commit信息；

2.HarmonyOS应用的单元测试和UI测试

2.1 测试概述

HarmonyOS中的自动化测试框架是arkxtest，支持JS/TS语言的单元测试框架（JsUnit）及UI测试框架（UiTest）。

  • JsUnit
    • 提供单元测试用例执行能力；
    • 提供用例编写基础接口，生成对应报告；
    • 用于测试系统或应用接口；
  • UiTest
    • 提供了API用于查找和操作界面的控件；
    • 支持用户开发基于界面操作的自动化测试脚本；

单元测试框架是测试框架的基础，提供了最基本的用例识别、调度、执行及结果汇总的能力。 UI测试框架主要对外提供了UiTest API供开发人员在对应测试场景。

2.2 新建&运行测试脚本

DevEco Studio中新建应用开发工程，其中ohosTest和test目录均为测试脚本所在的目录，只是有所不同：

企业微信截图_cb52b05c-2f6e-4aa1-a7b6-06345cdd89d4.png

  • Instrument Test: 测试用例存放在ohosTest测试目录下，需要运行在设备或模拟器上，支持单元测试和UI测试；

  • Local Test: 测试用例存放在test测试目录下，不需要运行在设备或者模拟器上，支持单元测试；

2.2.1 Local Test

a.在工程目录下打开待测试模块的ets文件，将光标置于代码的任意位置，右键 -> Show Context Actions -> Create Local Test创建测试类:

截屏2024-04-26 14.48.39.png

b.在弹出的Create Local Test窗口，配置如下参数：

  • Testing library: 测试类型，默认为DECC-ArkTSUnit
  • ArkTS name: 测试套件名称
  • Destination package: 存放的位置 企业微信截图_b354e403-965c-425c-9c3e-ff7eecd23510.png

c.DevEco Studio会在test目录下自动生成对应的测试类。在测试类中，DevEco Studio会生成对应方法的用例模板

具体测试代码需要开发者根据业务逻辑进行开发，具体请参考：单元测试框架。

d.可以直接在test文件夹上右键执行单元测试：

从图中可以看出，有三个选择：

  • 直接运行测试用例
  • Debug测试用例
  • 运行测试用例，并生成代码覆盖率文件

截屏2024-04-26 14.57.30.png

DevEco提供了4种运行模式：

  • 工程目录（test），在test文件夹上右键；
  • 测试文件（如LocalUnit.test.ets），在测试文件上右键；
  • 测试套件（describe），测试文件内部
  • 测试方法（it），测试文件内部

这里是以工程目录test为例。

e.查看生成的覆盖率文件:

当运行测试用例，并生成代码覆盖率文件之后，会在控制台输出覆盖率文件的路径：

企业微信截图_1076751e-cf1d-4629-8d24-be9373463c0d.png

我们打开该文件，可以看到包含了覆盖率信息，并且可以点击文件，查看具体文件的覆盖率信息：

截屏2024-04-26 15.04.20.png

需要注意的是，单元测试无法针对于UI描述进行测试，需要使用UI测试，下面是鸿蒙官方在工单中的回复：

Image (2).jpg

2.2.2 Instrument Test

Instrument Test的创建和执行过程和Local Test类似。

a.打开ets文件，将光标置于任意位置，右键->Show Context Actions -> Create Instrument Test创建测试类：

截屏2024-04-26 15.14.26.png

b.和Local Test一样，填写测试套件的名称；

c.DevEco Studio会在ohosTest目录下自动生成对应的测试类，并且也会生成对应方法的用例模板；

具体测试代码需要开发者根据业务逻辑进行开发，具体请参考：单元测试框架和UI测试框架。

d.运行Instrument Test测试用例 运行Instrument Test测试用例需要先将设备和电脑进行连接，将工程编译成带签名信息的HAP，再安装到真机设备或模拟器上运行。

运行Instrument Test测试用例的方法和模式和Local Test相同，不过针对的是ohosTest文件夹。

c.查看代码覆盖率 Instrument Test也会生成代码覆盖率文件，可以查看所有文件的覆盖率信息，和Local Test一样。

需要注意的是： Instrument Test针对于.ets文件的branch覆盖率，是基于.ets文件编译生成的.js文件进行统计的。

// index.ets:
@Entry  
@Component  
struct Index {  
  
@State name: string = "aa";  
  
build() {  
}  
  
}

// index.js
"use strict";  
class Index extends ViewPU {  
constructor(parent, params, __localStorage, elmtId = -1, paramsLambda = undefined, extraInfo) {  
super(parent, __localStorage, elmtId, extraInfo);  
if (typeof paramsLambda === "function") {  
this.paramsGenerator_ = paramsLambda;  
}  
this.__name = new ObservedPropertySimplePU("aa", this, "name");  
this.setInitiallyProvidedValue(params);  
}  
setInitiallyProvidedValue(params) {  
if (params.name !== undefined) {  
this.name = params.name;  
}  
}  
updateStateVars(params) {  
}  
purgeVariableDependenciesOnElmtId(rmElmtId) {  
this.__name.purgeDependencyOnElmtId(rmElmtId);  
}  
aboutToBeDeleted() {  
this.__name.aboutToBeDeleted();  
SubscriberManager.Get().delete(this.id__());  
this.aboutToBeDeletedInternal();  
}  
get name() {  
return this.__name.get();  
}  
set name(newValue) {  
this.__name.set(newValue);  
}  
initialRender() {  
}  
rerender() {  
this.updateDirtyElements();  
}  
static getEntryName() {  
return "Index";  
}  
}  
registerNamedRoute(() => new Index(undefined, {}), "", { bundleName: "com.example.studytest", moduleName: "entry", pagePath: "pages/Index" });  
//# sourceMappingURL=Index.js.map

该文件对应的覆盖率信息如下： Image (3).jpg

3. 获取测试覆盖率文件

从上面执行Local Test和Instrument Test生成的覆盖率文件路径可以看出，这个覆盖率文件的路径是固定的：

// Local test:
[项目根目录]/entry/.test/default/outputs/test/reports/index.html

// Instrument test:
[项目根目录]/entry/.test/default/outputs/ohosTest/reports/index.html

拿到文件之后，可以通过脚本获取指定标签下的数据，这样就可以自由组合覆盖率信息的文本了：

截屏2024-04-28 11.37.40.png

可以通过这两个路径获取覆盖率文件，那如果我们想实现最终目标的话，肯定就需要通过这个路径获取覆盖率文件进行解析，获取覆盖率信息了。

4.通过命令行构建HarmonyOS应用和执行HarmonyOS应用的测试用例

可以通过这个文档查看支持的命令行的能力： developer.huawei.com/consumer/cn…

4.1 应用编译构建相关任务

截屏2024-04-26 15.32.31.png

举例：

./hvigorw --mode module -p module=entry@default -p product=default -p buildMode=test -p ohos-test-coverage=true assembleHap --analyze --parallel --incremental --daemon

4.2 Local Test测试相关命令行

截屏2024-04-26 15.34.24.png

举例：

./hvigorw --mode module -p module=entry@default -p product=default -p pageType=page -p isLocalTest=true -p unitTestMode=true -p ohos-test-coverage=true -p buildRoot=.test UnitTestBuild --analyze --parallel --incremental --daemon

4.3 Instrument Test测试相关命令行

在官方文档中并没有发现Instrument Test测试相关的命令行，所以是通过手动的方式执行Instrument Test，然后在DevEco Studio中查看记录，获取到的相关命令如下：

// 构建Hap
./hvigorw assembleHap --mode module -p module=entry@default -p product=default -p buildMode=test -p ohos-test-coverage=true assembleHap --analyze --parallel --incremental --daemon  
// 构建测试用的Hap
./hvigorw --mode module -p module=entry@ohosTest -p buildMode=test -p ohos-test-coverage=true assembleHap --analyze --parallel --incremental --daemon 
// 通过hdc移除当前设备安装的Hap
hdc uninstall cn.test.aaa
// 通过hdc安装Hap
hdc install "${current_path}/entry/build/default/outputs/default/entry-default-unsigned.hap"  
hdc install "${current_path}/entry/build/default/outputs/ohosTest/entry-ohosTest-unsigned.hap"  
// 执行Instrument Test命令
hdc shell aa test -b cn.test.aaa -m entry_test -s unittest /ets/testrunner/OpenHarmonyTestRunner -s coverage true -s timeout 15000

虽然可以成功的执行Instrument Test测试用例，在执行Instrument Test命令时设置了coverage为true，但遗憾的是并没有生成相关的覆盖率文件，所以也提了一个工单，回复如下：

Image (4).jpg

5. 修改git commit信息

由于我们的开发流程需要Code Review，所以在执行完git commit之后，不能通过git push命令直接提交代码到仓库，需要执行cr命令。

通过构建一个脚本，可以执行鸿蒙项目的单元测试，然后读取覆盖率文件的信息，修改git commit信息，那这个脚本应该在什么时候触发呢？

Git hooks 是 Git 版本控制系统中的一个强大功能，允许用户在 Git 仓库的特定事件发生时运行自定义脚本。这些脚本（或钩子）可以自动化一些常见的任务，比如代码质量检查、代码格式化、测试运行、提交信息检查等。

Git hooks 可以在仓库的不同生命周期阶段触发，例如：

  • pre-commit：在提交之前运行，可以用来检查代码是否符合规范，或者是否所有测试都通过。
  • commit-msg：在提交信息准备完毕时运行，可以用来检查提交信息是否满足一定的格式要求。
  • pre-push：在推送更改到远程仓库之前运行，可以用来阻止不符合条件的更改被推送到远程。
  • post-merge：在合并操作完成后运行，可以用来执行一些合并后的清理工作或者重新构建项目。

如果直接执行git push的话，我们可以在pre-push中执行上面的脚本。幸好公司这边的开发环境也支持类似功能的pre-cr（提交cr前运行的脚本），我们就可以在pre-cr脚本执行上面的任务了，用文字描述一下在pre-cr脚本中执行的任务吧：

  1. 清理鸿蒙工程，移除测试产物；
  2. 执行单元测试，输出覆盖率文件；
  3. 读取覆盖率文件，拼接覆盖率文本信息；
  4. 获取最新的commit信息；
  5. 通过执行 git commit --amend 命令，插入覆盖率说明；

当开发者执行完git commit命令之后，提交cr的时候，就可以看到覆盖率信息了： 企业微信截图_33282d79-8f88-414e-8cec-fb4f9c4c40fa.png

avatar
文章
阅读
粉丝