C++|客户端单元测试实践—C++篇( 二 ) 客户端|机器|Linux

所以大部分依赖我们都是通过源码的形式导入到服务端机器中，编译出可执行文件安装。
生成镜像（可选）
在编译器、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表达式过多依赖的类对象不可构造/难以构造函数功能过多减少全局变量/静态变量的使用