背景
我们团队在淘宝中主要负责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工具。
部署到服务器运行
依赖安装
为了使单测工程和其他系统打通（如：钉钉群、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%），则不允许合并代码。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
