客户端单元测试实践 — 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++单元测试环境。

附录

  • 「单元测试最佳实践」https://www.jianshu.com/p/6413fcd58b71
  • 「从头到脚说单测——谈有效的单元测试(下篇)」http://testerhome.com/topics/30683
  • 「Frida - Anatomy of a code tracer 」https://medium.com/@oleavr/anatomy-of-a-code-tracer-b081aadb0df8

作者 | 思兼

原文链接

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

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/510569.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

基于 RTS 超低延时直播优化强互动场景体验

RTS 在阿里云视频直播的基础上进行底层技术优化,通过集成阿里云播放器 SDK,支持在千万级并发场景下节点间毫秒级延时直播的能力,弥补了传统直播存在 3~6 秒延时的问题,确保了超低延时、低卡顿、秒开流畅的直播观看体验。本文介绍了…

一文详解用 eBPF 观测 HTTP

前言 随着eBPF推出,由于具有高性能、高扩展、安全性等优势,目前已经在网络、安全、可观察等领域广泛应用,同时也诞生了许多优秀的开源项目,如Cilium、Pixie等,而iLogtail 作为阿里内外千万实例可观测数据的采集器&…

面向云时代的龙蜥操作系统,是 CentOS 替代的最佳选择

2022 开放原子全球开源峰会 OpenAnolis 分论坛上,阿里云智能基础软件产品经理张鹏程做了《面向云时代的龙蜥操作系统,应对 CentOS 停服的最佳选择》的主题分享,介绍了操作系统产业迎来新发展格局,龙蜥致力于成为 CentOS 迁移的最佳…

数据库治理利器:动态读写分离

背景 在分布式系统架构中,业务的流量都是端到端的。每个请求都会经过很多层处理,比如从入口网关再到 Web Server 再到服务之间的调用,再到服务访问缓存或 DB 等存储。 对于我们的系统来说,数据库是非常重要的一块。因此无论是在稳…

为什么我要迁移 SpringBoot 到函数计算

为什么要迁移? 我们的业务有很多对外提供服务的 RESTful API,并且要执行很多不同的任务,例如同步连锁 ERP 中的商品信息到美团/饿了么等平台,在线开发票等。由于各种 API 和任务执行的不确定性,经常会因为资源不足导致…

Ingress Nginx 接连披露高危安全漏洞,是否有更好的选择?

今年 K8s Ingress Nginx 项目接连披露了三个高危安全漏洞(CVE-2021-25745[1], CVE-2021-25746[2], CVE-2021-25748[3]),该项目也在近期宣布将停止接收新功能 PR,专注修复并提升稳定性。Ingress Nginx 作为 K8s 项目自带的网关组件…

浅谈数据仓库架构设计

1. 数据中台与DW/BI/DSS 个人认为数据中台本质上是一种新的适配大数据技术发展的新的“数据仓库-决策支持(商业智能)”架构。这个架构是构建在传统的架构基础之上,对传统架构的一种新的发展。 数据中台从企业的视角出发,要求企业…

RocketMQ 消息集成:多类型业务消息 - 定时消息

引言 Apache RocketMQ 诞生至今,历经十余年大规模业务稳定性打磨,服务了 100% 阿里集团内部业务以及阿里云数以万计的企业客户。作为金融级可靠的业务消息方案,RocketMQ 从创建之初就一直专注于业务集成领域的异步通信能力构建。 本篇将继续…

一文读懂 BizDevOps:数字化转型下的技术破局

我们正迈向数字经济时代,数字化转型成为普遍行动。未来绝大多数业务都将运行在数字基座之上,软件系统成为业务创新和发展的核心引擎。在这一趋势下,产品研发的交付能力面临巨大挑战,产品研发的交付实践和方法亟待变革。 BizDevOp…

地址标准化服务AI深度学习模型推理优化实践

导读 深度学习已在面向自然语言处理等领域的实际业务场景中广泛落地,对它的推理性能优化成为了部署环节中重要的一环。推理性能的提升:一方面,可以充分发挥部署硬件的能力,降低用户响应时间,同时节省成本;…

淘系数据模型治理最佳实践

导读:本次分享题目为淘系数据模型治理,主要介绍过去一年淘系数据治理工作的一些总结。 具体将围绕以下4部分展开 模型背景&问题2问题分析3治理方案4未来规划 模型背景&问题 1.整体情况 首先介绍一下淘系的整体数据背景。 淘系的数据中台成立…

【走进RDS】之SQL Server性能诊断案例分析

客户的困扰 前几天某程序员小王向阿里云咨询他的SQL Server数据库整体负载较高,是否有优化的方法?前几天另外一个工单则是需要阿里云工程师帮忙定位某一个时刻的数据库性能尖刺的问题。 这些都是常见的性能诊断工单,其实数据库性能诊断不仅…

用了那么久的 Lombok,你知道它的原理么?

序言 在写Java代码的时候,最烦写setter/getter方法,自从有了Lombok插件不用再写那些方法之后,感觉再也回不去了,那你们是否好奇过Lombok是怎么把setter/getter方法给你加上去的呢?有的同学说我们Java引入Lombok之后会…

Fury:一个基于JIT动态编译的高性能多语言原生序列化框架

Fury是一个基于JIT动态编译的多语言原生序列化框架,支持Java/Python/Golang/C等语言,提供全自动的对象多语言/跨语言序列化能力,以及相比于别的框架最高20~200倍的性能。 引言 过去十多年大数据和分布式系统蓬勃发展,序列化是其…

阿里云丁宇:以领先的云原生技术,激活应用构建新范式

8 月 11 日,2022 阿里云飞天技术峰会在深圳举行,会上阿里云提出云原生激活应用构建三大范式,并发布最新的产品与解决方案。基于分布式云容器平台 ACK One,实现多地域分布式系统一致管理;发布 ACK FinOps 解决方案&…

操作系统的“冷板凳”要坐多久?万字长文解读16年开源老兵的坚持

想知道内核研发是怎样的体验?操作系统的“冷板凳”得坐多久才有春天?本文对话龙蜥社区理事长马涛,畅所欲言聊开源,一起来看看那些开源润物细无声背后的故事以及龙蜥社区运营的道法术。 高门槛的 Linux 内核研发,如何支…

在阿里做前端程序员,我是这样规划的

前端程序员常问的几个问题 此文来自一次团队内的分享。我是来自大淘宝技术内容前端团队的胤涧,负责内容中台技术。我的习惯是每个新财年初都会进行一次分享《HOW TO BE AN EMINENT ENGINEER》,聊聊目前团队阵型、OKR、业务和技术大图,聊聊我作…

如何可视化编写和编排你的 K8s 任务

简介 K8s Job 是 Kubernetes 中的一种资源,用来处理短周期的 Pod,相当于一次性任务,跑完就会把 Pod 销毁,不会一直占用资源,可以节省成本,提高资源利用率。 阿里任务调度 SchedulerX 和云原生结合&#x…

前端智能化实践——可微编程

什么是可微编程 通过动画、动效增加 UI 表现力,作为前端或多或少都做过。这里以弹性阻尼动画的函数为例: 函数在 时是效果最好的。最终,实现成 JavaScript 代码: function damping(x, max) {let y Math.abs(x);// 下面的参数都是…

解析 RocketMQ 业务消息——“事务消息”

引言:在分布式系统调用场景中存在这样一个通用问题,即在执行一个核心业务逻辑的同时,还需要调用多个下游做业务处理,而且要求多个下游业务和当前核心业务必须同时成功或者同时失败,进而避免部分成功和失败的不一致情况…