简介: 我们团队在手淘中主要负责BehaviX模块,代码主要是一些逻辑功能,很少涉及到UI,为了减少双端不一致问题、提高性能,我们采用了将核心代码C++化的策略。由于团队项目偏底层,测试同学难以完全覆盖,回归成本较高,部分功能依赖研发同学自测,为了提高系统的稳定性,我们在团队中实行了单元测试,同时由于集团客户端C++单元测试相关经验沉淀较少,所以在此分享下团队在做单元测试中遇到的问题与解决思路,希望能对大家所有帮助。

作者 | 思兼
来源 | 阿里开发者公众号

背景

我们团队在手淘中主要负责BehaviX模块,代码主要是一些逻辑功能,很少涉及到UI,为了减少双端不一致问题、提高性能,我们采用了将核心代码C++化的策略。

由于团队项目偏底层,测试同学难以完全覆盖,回归成本较高,部分功能依赖研发同学自测,为了提高系统的稳定性,我们在团队中实行了单元测试,同时由于集团客户端C++单元测试相关经验沉淀较少,所以在此分享下团队在做单元测试中遇到的问题与解决思路,希望能对大家所有帮助。

为什么要使用单元测试

1、运行快

如果由测试同学手工测试,可能测试周期很长,对于功能比较复杂的功能,测试同学可能并不能完整覆盖所有预期链路,也可能由于某些操作而错过一些关键性步骤。

2、减少回归成本

使用单元测试,可以在每次修改代码后重新运行整套测试,尽可能保证新代码不会破坏现有功能。

3、优化代码结构

当代码耦合度非常大时,可能很难进行单元测试。为代码编写测试将自然地按照预期功能分离你的类。

单测工程搭建历程

单测环境搭建

运行环境的选择

C++工程由于一些三方库的依赖(需要准备多个平台的链接库),同一份代码想要在不同操作系统上运行稍微有点困难。

为了能够让单测工程快速运行起来,同时也方便开发同学调试,兼顾Android/iOS同学的开发习惯,在运行环境上支持单测支持在MacOS和Linux下运行。

依赖剥除

由于单测环境是运行在电脑环境的,所以必须要把一些外部依赖去除。

Java/OC的API依赖

涉及到跨语言通信时,通过NativeBridge封装,内部通过宏或cpp文件链接区分Android和iOS环境

外部库的依赖

一般采取源码依赖或打出多平台链接库(需要MacOS和Linux版本的依赖)的依赖方式解决。

单测框架

目前业内C++主流单测框架为google的gtest + gmock。

gtest提供了一些单元测试中的断言工具,gmock提供了一些mock功能,但是功能比较弱。

MOCK工具

gtest提供的gmock工具功能比较弱,只能通过继承的方式mock虚函数,对于C++来说是极其不方便的。

在Java中,成员方法是默认可以被派生类重写的,java主流mock工具mockito正是利用了这一特性来完成mock操作。在C++中,所有函数默认是不能被重写的,而且存在一些静态函数和工具函数,无法通过继承重写的方式完成mock。

最终我们基于开源的hook工具 frida 进行封装,实现了自己的mock工具。

部署到服务器运行

依赖安装

为了使单测工程和其他系统打通(如:钉钉群、Aone),单测工程同时也支持在Linux环境中运行。

因为C++语言的特殊性,从本机环境(MacOS)迁移到Linux并不是一帆风顺的。

集团的服务端机器使用的是CentOS,而且只能下载内网环境中已有的软件,版本也比较老,而且集团机器对C++的环境支持稍弱,如:编译器不支持C++11语法,CMake版本低,没有Clang编译器等。

所以大部分依赖我们都是通过源码的形式导入到服务端机器中,编译出可执行文件安装。

生成镜像(可选)

在编译器、CMake等工具安装好了之后,可以为当前环境创建docker镜像,这样下次就能部署到其他机器直接使用了。

外围功能建设

覆盖率

单测代码覆盖率

通过增加编译参数 -fprofile-arcs 和 -ftest-coverage,在编译完成后每个源文件会生成对应的.gcno文件,在程序运行结束时会生成.gcda文件,然后可以在单元测试运行完成后,使用lcov/gcov,统计代码运行的覆盖率。

注意,推荐使用动态链接的方式将你的待测工程库链接到每个测试用例中,如果使用静态链接,在单元测试运行完成后可能会有一些没有被任何用例覆盖到的文件没有生成.gcda文件,在计算代码覆盖率时这些源文件会被遗漏。

增量代码覆盖率

使用git merge-base可以获取两次提交最佳的公共祖先。

拿到最佳公共祖先与当前节点的提交记录,通过git diff和git blame,就可以获得两次提交的增量代码行,结合代码覆盖率可以计算出增量代码覆盖率。

内存泄漏检查

C++代码很容易写出内存泄漏,所以我们在单测工程中集成了valgrind工具,能有效的检测出内存泄漏的代码。

下面是一个简单的示例

钉钉群播报

每次代码合并到develop分支的时候,钉钉群中会播报本次测试的通过率以及代码覆盖率与上次合并时时差值等信息,方便大家及时修复问题,通过覆盖率增长差值也可以调动团队写单测的积极性。

code review卡口

在提交code review时,大家可以看到本次代码的单测通过率、单测覆盖率、增量覆盖率等信息,如果单元测试运行没有通过,或增量覆盖率卡口未通过(目前团队中要求增量单测覆盖率达到90%),则不允许合并代码。

单元测试实践

如何编写有效的单元测试用例

单元测试的组成部分

一般单元测试由以下几部分组成

  • 测试数据:尽可能稳定,减少对不确定性因素的依赖
  • 逻辑执行体:要明确当前测试用例测试的是哪个函数、哪个分支逻辑,不要一次性覆盖大多
  • 结果校验:尽可能完整,不要只校验函数返回值

单元测试的原则

单元测试必须遵循的原则:

  • 独立性:单元测试是独立的,可以单独运行,并且不依赖于任何外部因素,如文件系统或数据库。
  • 幂等性:每次运行单元测试应与其结果一致,测试中不要依赖如时间、日期等不确定因素
  • 快速:不要依赖网络请求等耗时操作

经验小结

编写单元测试时建议从以下角度思考

  • 实现什么功能,处理哪些数据,最终输出什么?
  • 异常和边界在哪里?
  • 函数的关键结果是否都验证到?包含返回值和中间值。
  • 函数的风险在哪里,哪部分逻辑不太自信,最容易出错?
  • 并不是所有函数都需要单测,如get/set等逻辑比较简单的的,不一定需要写。

提高代码的可测试性

C++是一门多范式的语言,而且由于C+语言本身的一些特性(RAII,模板等),网上很多基于Java等语言总结出来的提高可测试性的方法对C++来说可能过于麻烦,如依赖注入等,不一定特别适用。

下面整理了一些简单常用能提高可测试性的方式。

影响可测试性的常见因素

  • 外部依赖过多,需要mock
  • 数据依赖链过长,导致构造测试数据麻烦
  • 分支逻辑过于复杂
  • 全局变量/静态变量
  • 内部lambda表达式过多
  • 依赖的类对象不可构造/难以构造
  • 函数功能过多

减少全局变量/静态变量的使用

如果你的对象依赖了一些全局变量/静态变量,而且这些全局变量会在多个测试case使用,这种情况是比较难测试的,你不得不在每个测试用例结束之后手动重置全局变量。这样不符合单测测试的独立性原则,所以应该尽量避免使用全局变量。

class MyTest {
public: int GetIndex() {
return index++;
} static int index; //静态变量
}; int MyTest::index = 0; TEST(test, demo) {
ASSERT_EQ(0, MyTest().GetIndex());
} TEST(test, demo2) {
ASSERT_EQ(0, MyTest().GetIndex()); //Error
}
TEST(test, demo) {
MyTest::index = 0;
ASSERT_EQ(0, MyTest().GetIndex());
}
TEST(test, demo2) {
MyTest::index = 0;
ASSERT_EQ(0, MyTest().GetIndex());
}

迪米特法则

1、如果你代码中引入一些复杂的外部依赖,可以考虑将依赖转移给调用方

如:

class MyClass {
public:
void doSomething() {
if(getUserManager().getUser(123).getProfile().isAdmin()) { //bad 复杂的依赖链
//xxxx
} else { }
}
};
class MyClass {
public:
void doSomething(bool isAdmin) { //简单的参数依赖
if(isAdmin) {
//xxxx
} else { }
}
};

2、直接依赖需要的参数,避免依赖类似于Context大而全的参数(可能非常难以构造)

如:

class MyClass {
public: void processOrderBefore(const UserContext & userContext) { //修改之前
const User & user = userContext.getUser();
const PlanLevel & level = userContext.getLevel();
const Order & order = userContext.getOrder(); // ... process
} void processOrderAfter(const UserContext & userContext) { //修改后
const User & user = userContext.getUser();
const PlanLevel & level = userContext.getLevel();
const Order & order = userContext.getOrder(); processOrderAfter(user, level, order); //核心逻辑抽成新的函数
} void processOrderAfter(const User & user, const PlanLevel & level,const Order & order) {
//只需要对新封装函数进行单元测试即可
// ... process
}
};

封装分支逻辑

如果一个函数中分支太多,可以考虑将不同分支封装成不同的函数处理,然后对封装的函数分别编写单元测试用例。

合理使用MOCK工具

考虑在以下场景使用mock工具,可以减少你的单元测试成本

  • 代码中依赖的某个功能在你本次测试并不关心,如:db数据读取,发请求
  • 测试用例依赖一些复杂的数据源,如:db数据读取,流水线上游数据,网络请求
  • 一些非幂等性的函数调用或者结果返回不稳定的函数调用,如:随机数获取,时间获取,db写入
  • 对象的某些状态难以创建或者重现,如:网络错误或者文件读写错误
  • 验证一些中间过程值,如:你的函数没有返回值,或者中间过程值不方便验证,可以mock中间某个函数调用来验证中间过程结果是否正确

尝试测试驱动开发(TDD)

如果你的需求所要实现的功能相对明确,那么可以先把接口定义出来,写一个最简单的实现运行起来,为其补充单元测试用例,然后再一步步完善具体实现细节。

如果不能先写测试用例也没关系,重要的是在开发中尽早编写测试测试,不要将它们延迟到最后,这样可以及时重构你的代码。

常见误区

只测试正常数据

应当尽量补充一些特殊值(如空值、边界值)或异常数据,以校验目标函数在不同的输入是否符合预期,尽量覆盖多的代码分支逻辑。

结果校验不完整

如果你的目标测试函数中对属性进行了修改,那么应该尽可能校验这些修改是否符合预期,而不是单单只校验函数返回值。

输入数据过于复杂

  • 生成测试输入数据的代码应当避免与实际工程代码耦合,如:读取db或从流水线上游产生等
  • 使用最小数据依赖的原则,只输入对当前测试用例会产生影响的数据即可。
  • 如果数据源构造过于复杂,可以将一个大的测试用例拆分成多个小的测试用例。

测试代码存在分支条件

避免测试用例代码中使用if、switch等分支逻辑,保持用例尽量简单,如果需要测试不同分支的代码逻辑,应该拆分成多个测试用例。

维护测试用例

  • 重构代码时,应该同步修改测试用例
  • 发现新增Bug时,应当将能验证此Bug被修复的测试用例的补充到单元测试工程中

测试用例命名规则参考

TEST_F(TestUCPPipelineCenter, checkTaskInProcess_重复触发_true);
测试宏 被测试类名, 被测试函数名_简单描述核心测试逻辑_要校验的结果值

小结

我们小组的单元测试工程已经稳定运行了一段时间,代码提交流程也逐步固化下来了,如下图所示。后续我们会寻找一些指标去量化衡量单元测试所带来的收益。希望本文能帮助大家更加快捷地搭建C++单元测试环境。

附录


重磅来袭!2022上半年阿里云社区最热电子书榜单!

千万阅读量、百万下载量、上百本电子书,近200位阿里专家参与编写。多元化选择、全领域覆盖,汇聚阿里巴巴技术实践精华,读、学、练一键三连。开发者藏经阁,开发者的工作伴侣~

点击这里,查看详情。

原文链接:https://click.aliyun.com/m/1000352260/

本文为阿里云原创内容,未经允许不得转载。

客户端单元测试实践——C++篇的更多相关文章

  1. Golang 高效实践之并发实践context篇

    前言 在上篇Golang高效实践之并发实践channel篇中我给大家介绍了Golang并发模型,详细的介绍了channel的用法,和用select管理channel.比如说我们可以用channel来控 ...

  2. ABP框架实践基础篇之开发UI层

    返回总目录<一步一步使用ABP框架搭建正式项目系列教程> 说明 其实最开始写的,就是这个ABP框架实践基础篇.在写这篇博客之前,又回头复习了一下ABP框架的理论,如果你还没学习,请查看AB ...

  3. (转)[jQuery]使用jQuery.Validate进行客户端验证(初级篇)——不使用微软验证控件的理由

    以前在做项目的时候就有个很大心病,就是微软的验证控件,虽然微软的验证控件可以帮我们完成大部分的验证,验证也很可靠上手也很容易,但是我就是觉得不爽,主要理由有以下几点: 1.拖控件太麻烦,这个是微软控件 ...

  4. 【HELLO WAKA】WAKA iOS客户端 之一 APP分析篇

    由于后续篇幅比较大,所以调整了内容结构. 全系列 [HELLO WAKA]WAKA iOS客户端 之一 APP分析篇 [HELLO WAKA]WAKA iOS客户端 之二 架构设计与实现篇 [HELL ...

  5. 实践详细篇-Windows下使用VS2015编译的Caffe训练mnist数据集

    上一篇记录的是学习caffe前的环境准备以及如何创建好自己需要的caffe版本.这一篇记录的是如何使用编译好的caffe做训练mnist数据集,步骤编号延用上一篇 <实践详细篇-Windows下 ...

  6. 我的Spark SQL单元测试实践

    最近加入一个Spark项目,作为临时的开发人员协助进行开发工作.该项目中不存在测试的概念,开发人员按需求进行编码工作后,直接向生产系统部署,再由需求的提出者在生产系统检验程序运行结果的正确性.在这种原 ...

  7. 实践详细篇-Windows下使用Caffe训练自己的Caffemodel数据集并进行图像分类

    三:使用Caffe训练Caffemodel并进行图像分类 上一篇记录的是如何使用别人训练好的MNIST数据做训练测试.上手操作一边后大致了解了配置文件属性.这一篇记录如何使用自己准备的图片素材做图像分 ...

  8. 提高软件质量实践——Facebook 篇

    提高软件质量实践——Facebook 篇 Facebook 从 2004 年的哈佛校园的学生项目在短短的 7~8 年的时间中快速增长为拥有 10 亿用户的世界上最大的社交网络,又一次见证了互联网创业成 ...

  9. atitit.jndi的架构与原理以及资源配置and单元测试实践

    atitit.jndi的架构与原理以及资源配置and单元测试实践 1. jndi架构 1 2. jndi实现原理 3 3. jndi资源配置 3 3.1. resin  <database> ...

  10. [jQuery]使用jQuery.Validate进行客户端验证(初级篇)

    以前在做项目的时候就有个很大心病,就是微软的验证控件,虽然微软的验证控件可以帮我们完成大部分的验证,验证也很可靠上手也很容易,但是我就是觉得不爽,主要理由有以下几点: 1.拖控件太麻烦,这个是微软控件 ...

随机推荐

  1. PBKDF2算法:保障密码安全的利器

    PBKDF2算法起源: PBKDF2(Password-Based Key Derivation Function 2)算法是一种基于密码的密钥派生函数,最初由RSA实验室的密码学家提出,用于从密码中 ...

  2. RV1126编译过程

    一.编译环境 1.目标系统:ubuntu 22.04 LTS 2.投屏器SDK下载: 链接:https://pan.baidu.com/s/1OJQafxm38FnbshMEu432Og 提取码:o6 ...

  3. 工作记录:Stylus基础教程及应用

    前言 传统CSS的缺陷 css的可重用性差.代码冗余量大.不支持语言特性如变量循环及方法等(虽然css也在慢慢支持,比如现在的css变量等,但明显这些远远不够). 三大预处理 于是预处理器出现了: 2 ...

  4. JavaScript知识总结 终结篇--面向对象,垃圾回收与内存泄漏

    这里给大家分享我在网上总结出来的一些知识,希望对大家有所帮助 一.面向对象 一般使用字面量的形式直接创建对象,但是这种创建方式对于创建大量相似对象的时候,会产生大量的重复代码.但 js和一般的面向对象 ...

  5. 记录--Three.js入门教程——教不会算我输

    这里给大家分享我在网上总结出来的一些知识,希望对大家有所帮助 在javascript中使用Three.js设计并且实现3D场景是一个很有意思的事情,因为在浏览器中就能够渲染出3D场景,非常简单和轻便. ...

  6. hdfs disk balancer 磁盘均衡器

    目录 1.背景 2.hdfs balancer和 hdfs disk balancer有何不同? 3.操作 3.1 生成计划 3.2 执行计划 3.3 查询计划 3.4 取消计划 4.和disk ba ...

  7. Kingbase ES 自定义聚合函数浅析

    文章概要: 基于前面的博文<Kingbase ES 自定义聚合函数和一次改写案例>这篇文章,我们只考虑了自定义聚合函数非并行的情况, 因此,本篇文章将着重解析一下使用PLPGSQL编写并行 ...

  8. RabbitMQ 6种模式的练习,以及知识梳理

    常用的模式有Simple.Work.Fanout.Direct.Topic.Headers,可以通过设置交换机类型和配置参数来实现各个模式 简单模式(Simple) 工作模式(Work) 工作模式是考 ...

  9. Impala 高性能、低延迟的大数据查询引擎

    Impala是什么? Impala提供对大数据更快速,交互式 SQL查询. Impala支持对存储在HDFS.HBase及S3等数据查询. Impala使用和Hive相同的元数据.SQL定义.ODBC ...

  10. #dp,二项式反演,容斥#CF285E Positions in Permutations

    题目 问有多少个长度为 \(n\) 的排列 \(P\) 满足 \(|P_i-i|=1\) 的 \(i\) 的个数恰好为 \(k\) 个 分析 设 \(dp_{i,j,k}\) 表示前 \(i\) 个数 ...