背景

我们团队在淘宝中主要负责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 （地址：https://github.com/frida/frida）进行封装，实现了自己的mock工具。

	frida	gmock
普通成员函数	✅	❌
虚函数	✅	✅
静态函数	✅	❌
final函数	✅	❌
无需为mock重构代码	✅	❌

▐部署到服务器运行依赖安装

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

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

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

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

依赖安装

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

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

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

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

▐外围功能建设覆盖率

单测代码覆盖率

通过增加编译参数 -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());}

迪米特法则

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

如：

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 {                    }    }};

直接依赖需要的参数，避免依赖类似于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++单元测试环境，限于本人水平，如有不足或错误之处欢迎批评指正。

关键词： 单元测试 测试用例 全局变量 代码覆盖率 静态变量