C/C++ 单元自动化测试解决方案实践

来源：互联网收集：自由互联发布时间：2022-06-01

本文主要介绍如何利用GCC插件来实现提升C/C++开发者的单元效率工具解决方案。 vivo 互联网服务器团队 - Li Qingxin C/C++ 开发效率一直被业内开发人员诟病，单元测试开发效率也是如此，以

本文主要介绍如何利用GCC插件来实现提升C/C++开发者的单元效率工具解决方案。

vivo 互联网服务器团队 - Li Qingxin

C/C++ 开发效率一直被业内开发人员诟病，单元测试开发效率也是如此，以至于开发人员不愿花时间来写单元测试。那么我们是不是可以通过改善编写单元测试的效率来提升项目的测试用例覆盖率？

本文主要介绍如何利用GCC插件来实现提升C/C++开发者的单元效率工具解决方案，希望对大家在提升单元测试效率上有所启发。

一、动机

上图展示了C/C++单元测试的基本流程，在日常开发过程中写单元测试是一项比较大工程量的事情，C/C++ 目前单元测试代码都需要自己手动写，而且对于一些私有方法打桩就更加麻烦。

目前业内无开源的自动化测试框架或者工具，倒是有一些商业的自动测试工具，下图展示了我们自动化测试工具及单元测试库：

即使开源界有gtest等测试库的支持，我们仍然需要编写大量的单元测试用例代码。对于一些private、protected的类方法，编写单元测试用例的效率就更低，需要手动打桩（mock)。同时我们分析测试用例发现，存在很多边界的用例，它们基本上都是很固定或者有一定模式，比如int 最大最小值等。

如何改善编写单元测试的效率，提升C/C++同学开发效率以及程序质量？我们可以通过提取源文件中的函数、类等信息，然后生成对应的单元测试用例。自动生成用例时需要依赖函数的声明、类的声明等信息，那么我们应该如何获取这些信息呢？

例如：如下的函数定义：

void test(int arg) {}

我们希望能够从上面的函数定义中得到函数的返回值类型、函数名称、函数参数类型、函数作用域。通常我们可以通过以下几种方式得到：

1.1 方法1：使用正则表达式

无奈C/C++ 格式比较复杂能够虽然能够使用多种组合来获取对应的函数声明等信息：

void test(int arg){}
void test1(template<template<string>> arg,...){}
void test2(int(*func)(int ,float,...),template<template<string>> arg2){}

那么就需要写一系列的正则表达式：

提取函数名称、参数名：[z-aA-Z_][0-9]+
提取函数返回值：^[a-zA-Z_]

关键词提取出来了，但是他有一个很大的问题：怎么判断文件中书写的代码是符合C/C++语法描述呢？

1.2 方法2：使用flex/bison 分析c/c++源码文件

这当然是一种很好的方式，但是工作量巨大，相当于实现一个具备词法、语法分析器简易版本的编译器，而且要适配不同的语法格式，虽然bison可以解决上述的如何判断语法是否正确问题，但是仍然很复杂。

1.3 方法3：利用编译已经生成的AST 来生成代码

通常我们了解到的GCC编译的过程是以下四个阶段：

源文件->预处理->编译->汇编→链接

但实际上GCC为了支持更多的编程语言、不同的CPU架构做了很多的优化，如下图所示：

上图展示了GCC处理源码及其他优化过程，在前端部分生成的Generic 语言是gcc编译过程中为源码生成的一种与源码语言无关的抽象语法表现形式（AST）。既然GCC编译过程中生成了AST树，那么我们可以通过GCC插件来提取GCC 前端生成的抽象语法树关键信息比如函数返回值、函数名称、参数类型等。总体难度也很高，一方面业内可参考资料很少，只能通过分析GCC的源码来分析AST语法树上的各个节点描述。

本文所描述的自动化生成单元测试用例的解决方案（我们称之为TU：Translate Unit，后文统称为TU）就是基于方法3来实现的，下面我们先来看看我们的自动化测试用例解决方案的效果展示。

二、效果展示 2.1 业务代码零修改，直接使用TU生成边界用例

在该用例中我们不需要修改任何业务代码就能够为业务代码生成边界测试用例，而且函数参数可边界值实现全排列，大大降低用例遗漏风险。大家可能发现这种没有做任何修改生成的用例是没有断言的，虽然没有断言，它仍然能够帮助发现单元是否会存在边界值引起coredump。

那么如果想要给他加上断言、mock函数，是否没有办法呢？通过C++11 [[]] 新的属性语法，只需要在方法声明或者定义时添加下根据TU的格式添加断言即可，对业务逻辑无侵入。

2.2 使用注解tu::case生成用户自定义用例

很多情况下默认生成的边界测试用例还不能覆盖到核心逻辑，所以我们也提供tu::case 来给用户自定义自己的测试用例及断言。比如有一个int foo （int x,long y) 方法，现在想新增一个测试用例返回值123，函数实参1,1000，那么只要在函数声明前加入，以下代码即可：

[[tu::case("NE","123","1","1000")]]

2.3 使用注解tu::mock 自动生成mock方法

开发过程中我们也常需要对某个方法进行mock（即对原有方法设置一个临时代替方法并且调用方式保持一致），比如某个函数访问Redis、DB这种情况下进行单元测试往往需要对这些方法进行mock，方便其他函数调用进行单元测试，为了方便进行单元测试我们往往会对其进行mock，所以为了方便开发人员进行快速的mock，所以我们提供了tu::mock 的注解帮助开发同学快速的定义注解，然后TU会自动生成对应的mock函数。例如：现在给foo_read 方法mock一个函数，让mock的函数返回10：