【可测试性实践】C++单元测试：gtest gmock

引言

google test是目前C++主流的单元测试框架，本文介绍如何在工程引入gtest和gmock，并提供入门参考示例。根据黄金圈思维我们先思考Why（为什么做），为什么我们要进行单元测试，为什么要引入mock手段来测试代码，然后再来思考How（怎么做），最后思考What（取得了什么效果）。

Why：为什么引入单元测试？

我们先来看测试金字塔，如下图所示：

图引自：https://anymindgroup.com/news/tech-blog/15053/

可以看到从下往上分别是：

Unit tests：单元测试
Service/Integration tests：集成测试、端到端测试
User Interface tests：用户界面测试

越接近代码的测试，速度也就越快，成本也就越低。单元测试就最贴近代码的，在开发过程中执行测试就越容易发现问题。另外覆盖率是测试金字塔的核心，越接近底层的测试覆盖率应该越高，所以我们通常会以代码覆盖率和增量代码覆盖率来佐证单元测试的效果。

我们引入单元测试有两个目标：

提升测试速度和降低测试成本
提升代码可测试性

但最终的目的只有一个：提升质量。

再来说说为什么引入mock：

解决环境依赖的问题（网络、数据库等）
更早的实现接口逻辑（在后端服务未准备好之前），减少等待
通过模拟真实对象更好的驱动进行代码设计

当然Why层面可以做更多的深入思考，这里主要是抛砖引玉。

How：如何使用gtest & gmock？

示例工程：UnitTestProj

在src/hello_test.cpp添加以下代码

#include <gtest/gtest.h>

TEST(HelloTest, BasicAssertions) {
    // Expect two strings not to be equal.
    EXPECT_STRNE("hello", "world");
    // Expect equality.
    EXPECT_EQ(7 * 6, 42);
}

代码解析：

TEST 宏定义了一个测试用例。
HelloTest 是测试套件的名称，可以包含多个测试用例。
BasicAssertions 是测试用例的名称，用于描述具体的测试内容。
EXPECT_STRNE("hello", "world") 断言两个字符串不相等。
EXPECT_EQ(7 * 6, 42) 断言两个数值相等。

在src/test_mock.cpp添加以下代码

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

// 定义一个接口
class MyInterface {
public:
    virtual ~MyInterface() = default;
    virtual int Foo(int x) = 0;
};


// 使用gmock生成Mock类
class MockMyInterface : public MyInterface {
public:
    MOCK_METHOD(int, Foo, (int x), (override));
};

TEST(MockTestSuite, MockTestCase) {
    MockMyInterface mock;
    EXPECT_CALL(mock, Foo(5)).Times(1).WillOnce(testing::Return(10));

    ASSERT_EQ(mock.Foo(5), 10);
}

代码解析：

定义了一个纯虚接口 MyInterface，其中包含一个纯虚函数 Foo，需要在派生类中实现。
使用 Google Mock 提供的 MOCK_METHOD 宏生成 MockMyInterface 类，该类继承自 MyInterface 并实现了 Foo 函数。MOCK_METHOD 宏的参数包括返回类型、函数名、参数列表和覆盖说明符（override）。
TEST(MockTestSuite, MockTestCase) 定义了一个测试用例，属于测试套件 MockTestSuite。
使用 EXPECT_CALL 宏设置期望的函数调用。在这里，期望 mock.Foo(5) 被调用一次，并返回 10。
使用 ASSERT_EQ 宏断言 mock.Foo(5) 的返回值是否等于 10。

CMake配置示例

cmake_minimum_required(VERSION 3.14)
project(UnitTestProj)

# 设置 C++ 标准
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

include(FetchContent)
FetchContent_Declare(
  googletest
  URL https://github.com/google/googletest/archive/03597a01ee50ed33e9dfd640b249b4be3799d395.zip
)
# For Windows: Prevent overriding the parent project's compiler/linker settings
set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
FetchContent_MakeAvailable(googletest)

# 启用测试
enable_testing()

# 添加头文件目录
include_directories(${CMAKE_SOURCE_DIR}/src)

# 链接Google Test和Google Mock库
include_directories(${gtest_SOURCE_DIR}/include ${gmock_SOURCE_DIR}/include)

# 添加测试源文件
add_executable(
  unit_test_demo
  src/hello_test.cpp src/test_mock.cpp
)

# 链接Google Test、Google Mock
target_link_libraries(unit_test_demo gtest gmock gtest_main)

# 包含Google Test的发现测试功能
include(GoogleTest)
# 使用gtest_discover_tests命令自动发现并运行unit_test_demo目标中的所有测试
gtest_discover_tests(unit_test_demo)

运行测试结果

What：单元测试带来什么好处？

当然从这个简单的demo是很难体现单元测试带来的好处的，这里需要用实际的项目数据来进行佐证，但这往往是最难的部分，并且具有一定的滞后性，因为单测短期内对研发一定会带来成本的提升，需要自上而下认可并愿意投入资源去提升。

这里提供一些业界的参考指标，在我们引入单元测试后，尝试使用如下指标来衡量成果：

代码覆盖率：使用工具（如 gcov、JaCoCo）生成覆盖率报告，目标是达到 80% 以上的行覆盖率和分支覆盖率。
缺陷检测率：统计单元测试发现的缺陷数量和上线后发现的缺陷数量，目标是单元测试发现 70% 以上的缺陷。
测试执行时间：确保单元测试套件在 5 分钟内完成执行，以便快速反馈。
测试通过率：目标是测试通过率达到 95% 以上，确保代码的稳定性。
测试维护成本：定期评估测试用例的维护成本，确保在代码变更时需要较少的修改。
覆盖的功能模块：确保所有关键功能模块都有对应的单元测试覆盖。

更多参考

ASSERT_ vs EXPECT_

关于gtest有两种类型的断言，我们在使用的时候可以参考以下对比：

特性	`ASSERT_` 系列断言	`EXPECT_` 系列断言
行为	断言失败时立即终止当前测试用例	断言失败时继续执行当前测试用例
适用场景	后续代码依赖于当前断言的结果	希望即使断言失败，后续代码仍然执行
示例	`ASSERT_EQ(a, b);`	`EXPECT_EQ(a, b);`