OpenHarmony实战开发： unittest单元测试的编写

news2024/9/25 5:23:48

背景

程序开发与单元测试二者密不可分，是每个开发人员的基本业务。当功能性代码开发完成后，要自行测试其是否满足设计预期，如果不满足就要回去完善代码，满足则可以提交功能代码及测试用例。

测试用例的另一个重要作用就是阅读者了解代码的“一扇窗”，因为测试用例是程序的入口。

测试用例要覆盖每个接口所有分支，即保证每个待测函数的功能是正常的。

多个接口序列化功能需要提供完整序列化组合测试用例，例如：Open(), DoSomething(), Close()。

以下用 msdp 组件 device_status 子系统下待测 utility.cpp 源文件为例进行说明。

一、向 Utility.cpp 增加单元测试

待测源文件属于通用的、独立的功能性 API，所以直接调用每个接口。

1. 待测源文件所在目录

.\base\msdp\device_status\utils\common\include\utility.h
.\base\msdp\device_status\utils\common\src\utility.cpp

2. UtilityTest 测试用例代码

不存在的文件进行添加，存在的进行修改。

3. UtilityTest 单元测试的编译

UtilityTest 名称是在./base/msdp/device_status/test/unittest/utils/BUILD.gn 中规定的。

./build.sh --product-name rk3568 --build-target UtilityTest --fast-rebuild
// 或者
./build.sh --product-name rk3568 --build-target ./base/msdp/device_status/test/unittest/utils:UtilityTest --fast-rebuild

4. UtilityTest 生成物目录

二、测试

将编译生成的物拷贝到本地测试目录，然后运行脚本，在测试目录 log 下查看运行日志

1. UtilityTest 测试目录

将生成物拷贝到测试目录下：

2. 运行 test_UtilityTest.bat 脚本进行测试

将如下脚本写到 test_UtilityTest.bat 文件，放置在 D:\Test\ 目录下。每次测试时就直接双击它就可以了，运行时的日志在 D:\Test\log\ 目录。

hdc shell mount -o rw,remount /
hdc hdc file send D:\Test\device_status\unit_out\UtilityTest /data 
pause

hdc shell power-shell setmode 602
hdc shell chmod 777 ./data/UtilityTest

hdc shell hilog -b D -D 0XD002220
hdc shell rm -rf ./data/log/hilog/*
hdc shell rm -rf ./data/log/faultlog/faultlogger/*
hdc shell hilog -w start
hdc shell hilog -r

hdc shell ./data/UtilityTest

hdc shell hilog -w stop
mkdir log\hilog
mkdir log\faultlogger
hdc file recv  ./data/log/hilog/ .\log\
hdc file recv ./data/log/faultlog/faultlogger/ .\log\
pause

3. 测试过程的日志

.\log\hilog: 当前用例执行的一般日志；
.\log\faultlogger: 当前用例执行的 Crash 崩溃日志，一般为空，若出现必须消除；

三、复盘覆盖率

有专业分支覆盖率测试工具检查用例执行后分支的覆盖情况，一般情况下每个函数不管是公有或者私有都调用到，则可以满足 60% 的覆盖率要求。但是本地没有这样的工具时，就要在待测源文件中每个函数的分支添加上特别的日志，执行用例后查看是否到达。

添加完日志，势必要编译源码所在子系统，编译完成后，将必要的文件推送到板子上，重启板子，然后进行如上测试。

1. 编译 device_status 子系统

 ./build.sh --product-name rk3568 --ccache --build-target device_status --fast-rebuild

编译完成后进行推送

2. 将子系统生成物拷贝到本地，然后推送到板子上已有位置，进行替换

生成物目录图：

拷贝到本地目录图：

3. 执行推送并重启板子的脚本

@echo off
::重新挂载
::author: wangyeyu
hdc shell mount -o rw,remount /

::@echo off
::指定起始文件夹， "%cd%"当前文件夹；%DIR%设置一个变量；%TAR_DIR_SYSTEM_LIB%表示手机下的目的路径
set DIR="%cd%"
echo DIR=%DIR%
set TAR_DIR_SYSTEM_LIB="/system/lib/"
set TAR_DIR_LIB="/lib/"
set TAR_DIR_SYSTEM_LIB_PLATFORMSDK="/system/lib/platformsdk/"
set TAR_DIR_LIB_PLATFORMSDK="/lib/platformsdk/"

set TAR_DIR_SYSTEM_LIB_MODULE="/system/lib/module/"
set TAR_DIR_LIB_MODULE="/lib/module/"

echo TAR_DIR_SYSTEM_LIB="%TAR_DIR_SYSTEM_LIB%"
 
:: 参数 /R 表示需要遍历子文件夹,去掉表示不遍历子文件夹
:: %%f 是一个变量,类似于迭代器,但是这个变量只能由一个字母组成,前面带上%%
:: 括号中是通配符,可以指定后缀名,*.*表示所有文件
 
for /R %DIR% %%f in (*.so) do ( 
    echo %%f
   hdc file send %%f %TAR_DIR_SYSTEM_LIB%
   hdc file send %%f %TAR_DIR_LIB%

   hdc file send %%f %TAR_DIR_SYSTEM_LIB_PLATFORMSDK%
   hdc file send %%f %TAR_DIR_LIB_PLATFORMSDK%

   hdc file send %%f %TAR_DIR_SYSTEM_LIB_MODULE%
   hdc file send %%f %TAR_DIR_LIB_MODULE%
)

::重启设备
hdc shell reboot
@pause

四、测试用例编写的注意细节

函数、文件、文件夹、生成物命名要符合已有规范；
测试用例放置的位置首先符合已有规划，如果首次在子系统中添加单元测试，一般集中放置在子系统根目录，但是子系统非常庞大，则放置在待测源码就近位置；
测试用例要覆盖到待测接口中的所有分支，极其意外的分支无法覆盖除外；
每个测试用例测试一条分支；
测试用例必须包括正常用例和异常用例；
测试用例一般从最外接口调起，他会从上到下覆盖所有正常分支；
构造对象及参数直接调用待测源文件接口的情况：暂时不能覆盖待测源文件中大部分正常分支，或者从上层无法构造待测源文件中包含的异常分支（场景），待测源文件可能远离接口；
对于新增加的文件，版权年份必须是当前年份；
直接调用待测接口及私有、保护函数、变量时，需要在 BUILD.gn 中添加

  cflags = [
    "-Dprivate=public",
    "-Dprotected=public",
  ]

修改或者新添加的 BUILD.gn 要用格式化命令进行格式：
例如：

$ sudo gn format ./base/msdp/device_status/test/unittest/utils/BUILD.gn 
// 或者
$ ./prebuilts/build-tools/linux-x86/bin/gn format ./base/msdp/device_status/test/unittest/utils/BUILD.gn

五、小结

单元测试用例地编写属于简单的、必要的、能够体现产出的工作，建议新手小伙们积极承接。

本文档经过作者认真编写、实测有效，具有类似工作的实际指导意义，建议收藏！

最后

小编在之前的鸿蒙系统扫盲中，有很多朋友给我留言，不同的角度的问了一些问题，我明显感觉到一点，那就是许多人参与鸿蒙开发，但是又不知道从哪里下手，因为资料太多，太杂，教授的人也多，无从选择。有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）资料用来跟着学习是非常有必要的。

为了确保高效学习，建议规划清晰的学习路线，涵盖以下关键阶段：

鸿蒙（HarmonyOS NEXT）最新学习路线