背景

1. 运行快

2. 减少回归成本

3. 优化代码结构

单测工程搭建历程

运行环境的选择

依赖剥除

Java/OC的API依赖

外部库的依赖

依赖安装

生成镜像（可选）

覆盖率

单测代码覆盖率

增量代码覆盖率

内存泄漏检查

钉钉群播报

code review卡口

单元测试实践

单元测试的组成部分

• 测试数据：尽可能稳定，减少对不确定性因素的依赖
• 逻辑执行体：要明确当前测试用例测试的是哪个函数、哪个分支逻辑，不要一次性覆盖大多
• 结果校验：尽可能完整，不要只校验函数返回值

单元测试的原则

• 独立性：单元测试是独立的，可以单独运行，并且不依赖于任何外部因素，如文件系统或数据库。
• 幂等性：每次运行单元测试应与其结果一致，测试中不要依赖如时间、日期等不确定因素
• 快速：不要依赖网络请求等耗时操作

经验小结

• 实现什么功能，处理哪些数据，最终输出什么？
• 异常和边界在哪里？
• 函数的关键结果是否都验证到？包含返回值和中间值。
• 函数的风险在哪里，哪部分逻辑不太自信，最容易出错？
• 并不是所有函数都需要单测，如get/set等逻辑比较简单的的，不一定需要写 。

影响可测试性的常见因素

• 外部依赖过多，需要mock
• 数据依赖链过长，导致构造测试数据麻烦
• 分支逻辑过于复杂
• 全局变量/静态变量
• 内部lambda表达式过多
• 依赖的类对象不可构造/难以构造
• 函数功能过多

减少全局变量/静态变量的使用

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工具

• 代码中依赖的某个功能在你本次测试并不关心，如：db数据读取，发请求
• 测试用例依赖一些复杂的数据源，如：db数据读取，流水线上游数据，网络请求
• 一些非幂等性的函数调用或者结果返回不稳定的函数调用，如：随机数获取，时间获取，db写入
• 对象的某些状态难以创建或者重现，如：网络错误或者文件读写错误
• 验证一些中间过程值，如：你的函数没有返回值，或者中间过程值不方便验证，可以mock中间某个函数调用来验证中间过程结果是否正确

尝试测试驱动开发（TDD）

只测试正常数据

结果校验不完整

输入数据过于复杂

• 生成测试输入数据的代码应当避免与实际工程代码耦合，如：读取db或从流水线上游产生等
• 使用最小数据依赖的原则，只输入对当前测试用例会产生影响的数据即可。
• 如果数据源构造过于复杂，可以将一个大的测试用例拆分成多个小的测试用例。

测试代码存在分支条件

• 重构代码时，应该同步修改测试用例
• 发现新增Bug时，应当将能验证此Bug被修复的测试用例的补充到单元测试工程中

  
  
    

   
   
     

    
    
      

    
    
      

   
   
     
   
   
     
TEST_F(TestUCPPipelineCenter, checkTaskInProcess_重复触发_true);测试宏 被测试类名，        被测试函数名_简单描述核心测试逻辑_要校验的结果值
  
  
    
  
  
    

   
   
     

  
  
    
  
  
    

   
   
     

  
  
    

小结

附录

• 「单元测试最佳实践」 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