有关网站开发的国外书籍,网站建设服务商推荐,长沙招聘信息最新招聘,接单网背景
我们团队在手淘中主要负责BehaviX模块#xff0c;代码主要是一些逻辑功能#xff0c;很少涉及到UI#xff0c;为了减少双端不一致问题、提高性能#xff0c;我们采用了将核心代码C化的策略。
由于团队项目偏底层#xff0c;测试同学难以完全覆盖#xff0c;回归成…
背景
我们团队在手淘中主要负责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 进行封装实现了自己的mock工具。 部署到服务器运行
依赖安装
为了使单测工程和其他系统打通如钉钉群、Aone单测工程同时也支持在Linux环境中运行。
因为C语言的特殊性从本机环境MacOS迁移到Linux并不是一帆风顺的。
集团的服务端机器使用的是CentOS而且只能下载内网环境中已有的软件版本也比较老而且集团机器对C的环境支持稍弱如编译器不支持C11语法CMake版本低没有Clang编译器等。
所以大部分依赖我们都是通过源码的形式导入到服务端机器中编译出可执行文件安装。
生成镜像可选
在编译器、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表达式过多依赖的类对象不可构造/难以构造函数功能过多
减少全局变量/静态变量的使用
如果你的对象依赖了一些全局变量/静态变量而且这些全局变量会在多个测试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());
}
迪米特法则
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工具
考虑在以下场景使用mock工具可以减少你的单元测试成本
代码中依赖的某个功能在你本次测试并不关心如db数据读取发请求测试用例依赖一些复杂的数据源如db数据读取流水线上游数据网络请求一些非幂等性的函数调用或者结果返回不稳定的函数调用如随机数获取时间获取db写入对象的某些状态难以创建或者重现如网络错误或者文件读写错误验证一些中间过程值如你的函数没有返回值或者中间过程值不方便验证可以mock中间某个函数调用来验证中间过程结果是否正确
尝试测试驱动开发TDD
如果你的需求所要实现的功能相对明确那么可以先把接口定义出来写一个最简单的实现运行起来为其补充单元测试用例然后再一步步完善具体实现细节。
如果不能先写测试用例也没关系重要的是在开发中尽早编写测试测试不要将它们延迟到最后这样可以及时重构你的代码。 常见误区
只测试正常数据
应当尽量补充一些特殊值如空值、边界值或异常数据以校验目标函数在不同的输入是否符合预期尽量覆盖多的代码分支逻辑。
结果校验不完整
如果你的目标测试函数中对属性进行了修改那么应该尽可能校验这些修改是否符合预期而不是单单只校验函数返回值。
输入数据过于复杂
生成测试输入数据的代码应当避免与实际工程代码耦合如读取db或从流水线上游产生等使用最小数据依赖的原则只输入对当前测试用例会产生影响的数据即可。如果数据源构造过于复杂可以将一个大的测试用例拆分成多个小的测试用例。
测试代码存在分支条件
避免测试用例代码中使用if、switch等分支逻辑保持用例尽量简单如果需要测试不同分支的代码逻辑应该拆分成多个测试用例。
维护测试用例
重构代码时应该同步修改测试用例发现新增Bug时应当将能验证此Bug被修复的测试用例的补充到单元测试工程中
测试用例命名规则参考
TEST_F(TestUCPPipelineCenter, checkTaskInProcess_重复触发_true);
测试宏 被测试类名 被测试函数名_简单描述核心测试逻辑_要校验的结果值
小结
我们小组的单元测试工程已经稳定运行了一段时间代码提交流程也逐步固化下来了如下图所示。后续我们会寻找一些指标去量化衡量单元测试所带来的收益。希望本文能帮助大家更加快捷地搭建C单元测试环境。 附录
「单元测试最佳实践」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
作者 | 思兼
原文链接
本文为阿里云原创内容未经允许不得转载。
