GoogleTest

Kessity

已于 2024-10-25 20:22:18 修改

阅读量409

点赞数 3

分类专栏： Tools 文章标签： c++

于 2024-10-25 11:07:20 首次发布

本文链接：https://blog.youkuaiyun.com/essity/article/details/143229262

版权

Tools 专栏收录该内容

12 篇文章

订阅专栏

一概述

文档
开发者虽然主要负责工程里的开发任务，但是每个开发完毕的功能都是需要开发者自测通过的，所以经常会听到开发者提起单元测试的话题。那么今天我就带大伙一起来看看大名鼎鼎的谷歌 C++ 测试框架 GoogleTest。
来看看谷歌官方是怎么介绍这个框架的：

Googletest 是由测试技术团队根据 Google 的特定要求和约束开发的测试框架。无论您是在 Linux，Windows 还是 Mac 上工作，如果您编写 C++ 代码，googletest 都可以为您提供帮助。它支持任何类型的测试，而不仅仅是单元测试。
虽然谷歌是根据特定的需求和限制条件来开发这个框架的，但是它自己也指明了这个框架还可以用于其它用途，比如作为模拟器使用，当然这就扯远了，暂且不提。

谷歌在开发这套框架的时候，是有一套基本的设计思路的。
他们认为测试应该是相互独立而且是可重复的。如果正在做的测试由于其他测试的成功或失败而受到影响，这无疑会令人感到痛苦。GoogleTest 通过在不同的对象上运行不同的测试来实现测试的相互隔离。当其中一个或多个测试失败时，测试框架还允许测试者继续单独运行测试用例以达到快速调试。测试应该组织良好，并反映测试代码的结构。有很多测试其实可以共享数据和子例程的，那么 Googletest 提供了测试套件的概念将相关测试分组，测试套件中的所有测试就可以共享数据和子例程了。这种模式其实很常见，并且使得测试易于维护，特别是当你需要切换到新的代码工程时，测试流程将极大简化。
像谷歌这种规模的科技企业，内部的 C++ 项目非常之多，还是跨平台的，那么就对测试框架有平台无关的要求了。GoogleTest 正是如此，无论你是用的是那款编译器，哪个平台，通吃。
当然，测试的过程中理应提供尽可能全面的信息帮助开发者理解执行软件过程，GoogleTest 也不例外。就算测试过程中，某个测试执行失败被停止了，测试框架也会继续其它测试。如果你不希望某个测试由于失败而停止，可以设置该测试为非致命报错(non-fatal)。像这样的测试过程，可以帮助开发者在单个运行-编辑-编译周期中找到尽可能多的问题 bug。这样的测试框架是不是很高效？
虽说问题 bug 出现就够令开发者讨厌的了，但是自测过程的繁琐事那就更糟心了(头发怎么掉得那么快)，比如，开发者除了需要测试具体内容还得自己跟踪测试清单。Googletest 就可以帮助你从这里边脱身出来，做一枚潇洒的码农。
这里问一句，你用过 JUnit 或 PyUnit 吗？如果有的话，那么 Googletest 对你来说真的是易如反掌了。据说 Googletest 是基于 xUnit 架构开发而来。至于什么是 xUnit 架构，有机会我再聊聊吧。
测试框架在测试过程中，基本的测试操作就是使用断言(assert)来验证测试代码的行为，崩溃或者断言失败都表示被测试代码的行为不正确，否则正确。

二初体验

来看一下简单的测试样例(环境配置安装会在后面有详细介绍)

#include <math.h>
#include <gtest/gtest.h>

int square(const int a)
{
    int b = a * a;
    if (b != b)
    {
        return -1;
    }
    else
    {
        return a * a;
    }
}

TEST(SquareTest, PositiveNos)
{ 
    ASSERT_EQ(0, square(0));
    ASSERT_EQ(36, square(6));
    ASSERT_EQ(324, square(18));
}

int main(int argc, char **argv)
{
    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

这个测试样例是为了测试函数 int square(const int a) 的行为是否正确。
编译生成可执行文件之后，运行起来
在这里插入图片描述
可以看到，上面总共有一个测试套件和一个测试。首先启动一次全局测试环境，使用框架提供的宏 TEST() 创建了一个测试套件，命名为 SquareTest，和一个测试，命名为 PositiveNos。然后，运行测试套件内包含的所有测试，测试通过 OK。全部测试结束后，卸载全局测试环境。汇总全部测试结果 PASSED。测试流程结束。

三断言

什么是断言？断言是用来对表达式执行比较的代码块，调用时类似函数。当表达式一致时，断言返回成功，否则失败。
googletest 的断言是一组宏定义。分为 ASSERT_* 和 EXPECT_* 两种。
比如

ASSERT_EQ(1, 2);
EXPECT_EQ(1, 2);

上面用到的两个断言都是比较输入的数据是否相等。主要区别是，ASSERT_* 在失败时终止程序运行，EXPECT_* 在失败时不会终止程序运行，但是都会返回错误信息。因而测试使用 EXPECT_* 可以发现更多的问题而不会打断测试流程。
那么 ASSERT_* 断言失败时，跟在其后的语句会被忽略执行，如果其中包含对资源的释放，那么就有会出现资源泄漏的问题，断言失败报错信息会附带有堆检查错误。这时出现的资源泄漏问题，真的有必要修复码？看具体情况而定。
另外，googletest 在断言失败后除了可以返回标准错误信息，还可以附带返回自定义错误信息，使用操作符 << 添加自定义错误信息。

ASSERT_EQ(1, 2) << "1 is not equal to 2";
EXPECT_EQ(1, 2) << "1 is not equal to 2";

任何可以传递给 ostream 的数据都可以作为自定义错误信息传递给断言，比如 C 字符串、string对象。
那么，测试的基本手段就是利用断言，除了判断型的断言之外，googletest 还提供了其它类型的断言用于协助测试，比如显式成功或失败、布尔类型断言、字符串比较断言等，详情可以前往官网查看手册。

四如何测试

前面提到在 googletest 中，测试的范围分为测试套件和单个测试。测试程序可以包含多个测试套件，一个测试套件可以包含多个测试。
简单的测试一般推荐使用 TEST 宏来定义单个测试。
一般的使用方式如下

TEST(test_suite_name, test_name) {
  // test body
}

test_suite_name 是测试套件名，test_name 是单个测试的名称，书写时都应该符合 C++ 的标识符规范，而且不能包含有下划线_。
那么 TEST 宏到底代表着什么？一起来看看 TEST 宏定义的源代码
在这里插入图片描述

这么多预定义处理，不妨尝试代入上面的一般使用方式，然后展开一下，展开如下

从展开后的代码，可以看到有一堆代码，最开始有两个断言 static_assert 用来判断输入的测试套件名和测试名长度是否大于1，所以要求 TEST 宏定义输入的测试套件名和测试名都不能为空。
然后基于 ::testing::Test 派生了一个类，类名是测试套件名和测试名串接后再在末尾加上 _Test。类内声明重写 TestBody() 方法。
TEST 宏定义后面的 {} 用于定义派生类的成员方法 TestBody() 的函数体，内部填写标准 C++ 的有效语句作为测试主体，当然也包含调用 googletest 提供的模块内容，注意这个代码块是没有返回值的。代码块执行的断言失败时，或者代码崩溃，则测试 test_name 失败，否则成功。
再来看个例子：

int square(const int a)
{
  // ...
}

TEST(SquareTest, PositiveNos) { 
    ASSERT_EQ(0, square(0));
    ASSERT_EQ(36, square(6));
    ASSERT_EQ(324, square(18));
}
 
TEST(SquareTest, NegativeNos) {
    ASSERT_EQ(1, square(-1));
    ASSERT_EQ(100, square(-10));
}

上面定义了两个测试 PositiveNos 和 NegativeNos，都属于测试套件 SquareTest。
googletest 在设计时就指定通过测试套件来汇总测试结果，所以验证同一个逻辑功能的测试应该定义在同一个测试套件内。

五测试夹具

在 googletest 里什么是测试夹具？
测试夹具这个概念是为了解决当你的同一个逻辑功能测试里，有多个测试共用测试数据或者配置的问题。
需要用到测试夹具的测试一般推荐使用 TEST_F 宏来定义单个测试。
一般的使用方式如下

TEST_F(FixtureTest, test_name) {
  // test body
}

不过，TEST_F 宏的第一个输入参数不仅仅是测试套件名称，同时也是测试夹具类名。这个测试夹具类需要自己基于类 ::testing::Test 派生实现。

class FixtureTest : public testing::Test {
protected:
void SetUp() override { ... }
void TearDown() override { ... }
// custom data
};

共用的测试数据或者配置就在这个派生类里添加即可。SetUp() 用于初始化数据和配置，TearDown() 用于卸载配置。
那么 TEST_F 宏到底代表着什么，和 TEST 宏的区别在哪？一起来看看 TEST_F 宏定义的源代码
在这里插入图片描述

这么多预定义处理，手痒代入一般的使用方式然后展开一下，展开如下

从展开后的代码来看，TEST_F 和 TEST 实现基本类似，那么使用时要遵循的规则也是一样的，除了需要传入自定义的基于 ::testing::Test 派生类，并且测试套件名就是测试夹具类名。
举个例子，有个模板类 Queue 的逻辑功能需要测试，它实现了 FIFO 的数据队列管理。

template <typename E>  // E 是元素类型
class Queue {
 public:
  Queue();
  void Enqueue(const E& element); // 数据入队
  E* Dequeue();  // 数据出队，如果队列为空则返回 NULL
  size_t size() const;  // 队列数据长度
  ...
};

然后需要基于 ::testing::Test 派生一个测试夹具类 QueueTest

class QueueTest : public ::testing::Test {
 protected:
  void SetUp() override {
     q1_.Enqueue(1);
     q2_.Enqueue(2);
     q2_.Enqueue(3);
  }
  // void TearDown() override {}
  Queue<int> q0_;
  Queue<int> q1_;
  Queue<int> q2_;
};

夹具类 QueueTest 内定义了三个队列数据对象。SetUp() 内对数据对象初始化，q0_ 保持为空，q1_ 入队一个数据，q2_ 入队两个数据。
为什么不实现 TearDown() 呢？TearDown() 本来的设计意图是卸载配置，不是刚好可以用来清理数据吗？是的，的确可以，不过这里有个更好的选择，就是使用类析构函数来对队列清空。这里有个建议就是，能用析构函数处理的，尽量用析构函数替代 TearDown()。因为用析构函数可以确保被调用而且调用的顺序不会乱，但不是说所有情况都建议用析构函数替代 TearDown()，这里不展开了。
接着调用 TEST_F 定义两个测试，基于测试夹具类 QueueTest，测试套件名也是 QueueTest，两个测试名分别为 IsEmptyInitially 和 DequeueWorks。

TEST_F(QueueTest, IsEmptyInitially)
{
  EXPECT_EQ(q0_.size(), 0);
}

TEST_F(QueueTest, DequeueWorks)
{
  int* n = q0_.Dequeue();
  EXPECT_EQ(n, nullptr);

  n = q1_.Dequeue();
  ASSERT_NE(n, nullptr);
  EXPECT_EQ(*n, 1);
  EXPECT_EQ(q1_.size(), 0);
  delete n;

  n = q2_.Dequeue();
  ASSERT_NE(n, nullptr);
  EXPECT_EQ(*n, 2);
  EXPECT_EQ(q2_.size(), 1);
  delete n;
}

上面的这两个测试定义，都会创建 QueueTest 类对象，分别创建而且不共用，所以数据不会相互影响。
第一个测试 IsEmptyInitially，googletest 框架会先创建 QueueTest 类对象 obj，调用 SetUp() 初始化数据和配置，执行测试。这里只执行了一个 EXPECT_EQ 断言，EXPECT_* 类型的断言失败后会返回失败信息，不会终止测试程序，继续下一步测试。然后调用 TearDown() 清理，最后执行对象 obj 的析构函数释放资源并退出当前测试。
第二个测试 DequeueWorks，执行流程与上一个类似。其中测试内容包含有 ASSERT_* 类别的断言，这种断言在失败后除了会返回失败信息，还会终止测试程序。如果断言失败之后的测试已没有意义，那么适合使用 ASSERT_* 类别的断言。

六测试调用过程

其它 C++ 测试框架在测试开始前，需要你把测试排列出来，但是 googletest 不需要这么麻烦。在 googletest 框架中，定义好测试后，只需要在 main 部分执行如下代码即可。

int main(int argc, char **argv)
{
    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

InitGoogleTest() 可以对程序的输入命令执行解析，基于这点可以通过命令行的方式控制测试框架的运行。
继续以上面的代码为例，大致流程如下

InitGoogleTest() 初始化测试框架。
RUN_ALL_TESTS() 启动测试。
查找测试套件内的测试。
保存配置标志。
创建 QueueTest 实例。
调用 QueueTest 实例的 SetUp() 初始化数据配置。
执行测试。
调用 QueueTest 实例的 TearDown() 卸载数据配置。
恢复配置标志。
重复第 3 步，直到所有测试执行完毕，RUN_ALL_TESTS() 返回 0 表示成功，否则失败。只能在主线程里调用 RUN_ALL_TESTS()。

在一般的测试里，如果在测试运行之前不需要做一些自定义的事情，而且这些事情无法在测试夹具和测试套件的框架中表达时，main 函数这部分其实都一样，那么 googletest 就在库 gtest_main 里提供了一个很方便的入口点，也就是帮你提前写好了 main 函数，你可以省去这部分，编译的时候记得链接库 gtest_main 即可。