单元测试干货C++ PC篇（续）

草帽路飞UU

单元测试实践
　　· 如何编写有效的单元测试用例
　　单元测试的组成部分
　　一般单元测试由以下几部分组成：
　　1. 测试数据：尽可能稳定，减少对不确定性因素的依赖。
　　2. 逻辑执行体：要明确当前测试用例测试的是哪个函数、哪个分支逻辑，不要一次性覆盖大多。
　　3. 结果校验：尽可能完整，不要只校验函数返回值。
　　单元测试的原则
　　单元测试必须遵循的原则：
　　1. 独立性：单元测试是独立的，可以单独运行，并且不依赖于任何外部因素，如文件系统或数据库。
　　2. 幂等性：每次运行单元测试应与其结果一致，测试中不要依赖如时间、日期等不确定因素。
　　3. 快速：不要依赖网络请求等耗时操作。
　　经验小结
　　编写单元测试时建议从以下角度思考：
　　1. 实现什么功能，处理哪些数据，最终输出什么？
　　2. 异常和边界在哪里？
　　3. 函数的关键结果是否都验证到？包含返回值和中间值。
　　4. 函数的风险在哪里，哪部分逻辑不太自信，最容易出错。
　　5. 并不是所有函数都需要单测，如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工具，可以减少你的单元测试成本：
　　1. 代码中依赖的某个功能在你本次测试并不关心，如：db数据读取，发请求。
　　2. 测试用例依赖一些复杂的数据源，如：db数据读取，流水线上游数据，网络请求。
　　3. 一些非幂等性的函数调用或者结果返回不稳定的函数调用，如：随机数获取，时间获取，db写入。
　　4. 对象的某些状态难以创建或者重现，如：网络错误或者文件读写错误。
　　5. 验证一些中间过程值，如：你的函数没有返回值，或者中间过程值不方便验证，可以mock中间某个函数调用来验证中间过程结果是否正确。
　　尝试测试驱动开发（TDD）
　　如果你的需求所要实现的功能相对明确，那么可以先把接口定义出来，写一个最简单的实现运行起来，为其补充单元测试用例，然后再一步步完善具体实现细节。
　　如果不能先写测试用例也没关系，重要的是在开发中尽早编写测试测试，不要将它们延迟到最后，这样可以及时重构你的代码。

　· 常见误区
　　只测试正常数据
　　应当尽量补充一些特殊值（如空值、边界值）或异常数据，以校验目标函数在不同的输入是否符合预期，尽量覆盖多的代码分支逻辑。
　　结果校验不完整
　　如果你的目标测试函数中对属性进行了修改，那么应该尽可能校验这些修改是否符合预期，而不是单单只校验函数返回值。
　　输入数据过于复杂
　　1. 生成测试输入数据的代码应当避免与实际工程代码耦合，如：读取db或从流水线上游产生等。
　　2. 使用最小数据依赖的原则，只输入对当前测试用例会产生影响的数据即可。
　　3. 如果数据源构造过于复杂，可以将一个大的测试用例拆分成多个小的测试用例。
　　测试代码存在分支条件
　　避免测试用例代码中使用if、switch等分支逻辑，保持用例尽量简单，如果需要测试不同分支的代码逻辑，应该拆分成多个测试用例。
　　· 维护测试用例
　　1. 重构代码时，应该同步修改测试用例。
　　2. 发现新增[url=]Bug[/url]时，应当将能验证此Bug被修复的测试用例的补充到单元测试工程中。
　　· 测试用例命名规则参考
　　TEST_F(TestUCPPipelineCenter, checkTaskInProcess_重复触发_true);
　　测试宏 被测试类名，        被测试函数名_简单描述核心测试逻辑_要校验的结果值


　　小结
　　我们小组的单元测试工程已经稳定运行了一段时间，代码提交流程也逐步固化下来了，如下图所示。后续我们会寻找一些指标去量化衡量单元测试所带来的收益。希望本文能帮助大家更加快捷地搭建C++单元测试环境，限于本人水平，如有不足或错误之处欢迎批评指正。