当前位置：首页 > news >正文

C++单元测试实战：从零掌握Google Test框架与工程实践

news 2026/7/13 6:22:41

1. 项目概述：为什么我们需要一个“测试神器”？

如果你写过C++，尤其是写过稍微复杂一点的C++项目，那你一定经历过这种场景：改了一行代码，编译运行，功能看起来正常，但心里总是不踏实，不知道会不会在某个你没注意到的角落里埋下了新的bug。或者，当你需要重构一个陈年老模块时，面对一堆错综复杂的函数调用，你根本不敢下手，因为你不知道你的修改会不会破坏现有的功能。这种对代码变更的恐惧，是每个开发者成长路上必须跨过的坎。而gtest，全称Google Test，就是Google开源出来，专门帮我们C++程序员解决这个问题的“神器”。它不是一个简单的“运行一下看看”的工具，而是一套完整的单元测试框架，能让你用写代码的方式，来定义、组织、运行和验证你的测试，把“心里不踏实”变成“运行通过，万事大吉”。

简单来说，gtest让你能为你写的每一个函数、每一个类，都配套写上一套“考题”。每次代码改动后，不用再手动去点各种界面、输入各种数据来验证，只需要一键运行所有“考题”，几分钟内就能知道这次改动有没有引入回归错误。这对于保证代码质量、支撑持续重构、以及团队协作来说，价值巨大。网上那些热词，像“c++面试题”、“c++八股文”，很多底层原理和边界条件的考察，用gtest写个测试用例来验证和理解，比死记硬背要高效十倍。接下来，我就以一个老C++程序员的角度，带你从零开始，把gtest这个神器用起来，让它成为你开发工具箱里的标配。

2. 环境搭建与第一个测试

理论说再多不如动手跑一遍。搭建gtest环境现在主要有两种主流方式：一种是直接用包管理工具下载编译好的库，另一种是从源码编译。对于新手，我强烈推荐使用CMake的FetchContent模块，它能自动下载、编译并集成gtest，无需你手动处理依赖，是最干净、最跨平台的方式。

2.1 使用CMake与FetchContent集成

假设你的项目目录结构如下：

my_project/ ├── CMakeLists.txt ├── src/ │ └── math.cpp │ └── math.h └── tests/ └── test_math.cpp

你的CMakeLists.txt可以这样写：

cmake_minimum_required(VERSION 3.14) project(MyGtestProject) # 设置C++标准 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 将src目录添加到头文件搜索路径 include_directories(${CMAKE_CURRENT_SOURCE_DIR}/src) # 定义你的主库（被测试的代码） add_library(math_lib src/math.cpp) # 通过FetchContent获取googletest include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG release-1.12.1 # 建议指定一个稳定版本标签 ) FetchContent_MakeAvailable(googletest) # 定义测试可执行文件 add_executable( run_unit_tests tests/test_math.cpp ) # 链接测试文件到你的库和gtest target_link_libraries( run_unit_tests math_lib GTest::gtest_main ) # 将测试添加到CTest，这样可以用`ctest`命令运行 include(GoogleTest) gtest_discover_tests(run_unit_tests)

这段CMake脚本做了几件事：首先声明项目并设置C++标准。然后，它没有让你去官网下载gtest的zip包，而是通过FetchContent_Declare告诉CMake：“去这个Git地址拉取指定版本的代码”。FetchContent_MakeAvailable会执行下载和编译。之后，我们创建了一个叫run_unit_tests的可执行文件，它由我们的测试代码test_math.cpp编译而来，并且需要链接我们自己的math_lib和gtest提供的GTest::gtest_main。最后两行是高级功能，把测试注册到CMake的测试框架里，方便集成到CI/CD流程。

注意：国内网络环境访问GitHub可能不稳定。如果FetchContent下载太慢或失败，你有两个备选方案：1）将GIT_REPOSITORY替换为国内镜像地址（如gitee上的镜像）；2）预先将googletest源码下载到本地，然后使用FetchContent_Declare(googletest SOURCE_DIR /your/local/path/to/googletest)。我个人的经验是，对于公司内部项目，更倾向于将gtest作为子模块（git submodule）引入，这样版本固定，所有开发者环境一致。

2.2 编写被测试代码与第一个测试用例

现在，我们来点简单的被测试代码。在src/math.h和math.cpp里定义一个加法函数：

// math.h #pragma once int Add(int a, int b); // math.cpp #include “math.h” int Add(int a, int b) { return a + b; }

接着，在tests/test_math.cpp中编写我们的第一个gtest测试：

#include “gtest/gtest.h” // 必须包含gtest头文件 #include “math.h” // 包含被测试模块的头文件 // 定义一个测试夹具（Test Fixture），这里我们先简单使用 // 实际上对于Add函数，直接使用TEST宏更简洁 TEST(TestMath, Add_PositiveNumbers) { EXPECT_EQ(Add(1, 2), 3); EXPECT_EQ(Add(10, 20), 30); } TEST(TestMath, Add_NegativeNumbers) { EXPECT_EQ(Add(-1, -2), -3); EXPECT_EQ(Add(-10, 5), -5); // 正负相加 } TEST(TestMath, Add_Zero) { EXPECT_EQ(Add(0, 0), 0); EXPECT_EQ(Add(100, 0), 100); }

代码非常直观。TEST是gtest的核心宏，它定义了一个测试用例。TEST(TestSuiteName, TestName)，第一个参数是测试套件名，用于逻辑分组相关的测试，这里我们用TestMath；第二个参数是具体的测试名，要尽可能描述清楚测试的场景，比如Add_PositiveNumbers。在测试用例内部，我们使用EXPECT_EQ这个“断言”（Assertion）来验证结果。它的意思是“期望相等”，如果Add(1, 2)的结果不等于3，测试就会失败，并打印出详细的错误信息。

2.3 编译与运行测试

在项目根目录下，执行标准的CMake流程：

mkdir build && cd build cmake .. make -j4

编译成功后，你会看到生成了一个run_unit_tests的可执行文件。直接运行它：

./run_unit_tests

你会看到类似如下的输出：

[==========] Running 3 tests from 1 test suite. [----------] Global test environment set-up. [----------] 3 tests from TestMath [ RUN ] TestMath.Add_PositiveNumbers [ OK ] TestMath.Add_PositiveNumbers (0 ms) [ RUN ] TestMath.Add_NegativeNumbers [ OK ] TestMath.Add_NegativeNumbers (0 ms) [ RUN ] TestMath.Add_Zero [ OK ] TestMath.Add_Zero (0 ms) [----------] 3 tests from TestMath (0 ms total) [----------] Global test environment tear-down. [==========] 3 tests from 1 test suite ran. (1 ms total) [ PASSED ] 3 tests.

看到最后的[ PASSED ] 3 tests.，恭喜你，你的第一个gtest测试全部通过了！这个过程就是单元测试的核心闭环：编写代码 -> 编写测试 -> 运行测试 -> 获得反馈。这个反馈是即时的、自动化的、可靠的。

3. gtest核心概念深度解析

搞定了“跑起来”，我们现在深入看看gtest提供的各种“武器”，理解它们的设计意图和适用场景，这样才能在真正复杂的项目里运用自如。

3.1 断言（Assertions）：测试的基石

断言是测试的灵魂，用来验证某个条件是否为真。gtest提供了丰富的断言宏，主要分两类：ASSERT_*和EXPECT_*。

ASSERT_*：致命断言。一旦失败，当前测试函数会立即终止，gtest会跳出这个TEST，继续运行下一个测试。通常用于验证前提条件，如果失败，后续验证没有意义。
EXPECT_*：非致命断言。失败后，会打印错误，但当前测试函数会继续执行。这能让你在一次测试运行中看到所有失败的点，便于调试。

如何选择？一个简单的原则：如果某个检查失败了，剩下的检查还有意义吗？比如，你要测试一个打开文件并读取的函数，如果ASSERT_TRUE(OpenFile())失败了，那后面的读取操作测试就没必要做了，用ASSERT_*。如果你在测试一个计算器的多种运算，测试加法失败了，你仍然希望继续测试减法和乘法，那就用EXPECT_*。

常用的断言宏家族：

布尔值检查：

ASSERT_TRUE(condition); // 期望条件为真 EXPECT_FALSE(condition); // 期望条件为假

数值比较（最常用）：

EXPECT_EQ(val1, val2); // 等于 ASSERT_NE(val1, val2); // 不等于 EXPECT_LT(val1, val2); // 小于 EXPECT_LE(val1, val2); // 小于等于 EXPECT_GT(val1, val2); // 大于 EXPECT_GE(val1, val2); // 大于等于

实操心得：对于浮点数的比较，千万不要直接用EXPECT_EQ！因为浮点数有精度误差。gtest提供了专门的浮点数比较：

EXPECT_FLOAT_EQ(0.1f, 0.1f); // 默认容忍4 ULP误差 EXPECT_DOUBLE_EQ(0.1, 0.1); // 默认容忍4 ULP误差 // 或者指定绝对误差/相对误差 EXPECT_NEAR(actual, expected, absolute_error); // 绝对误差 // 使用浮点数匹配器更灵活（后续会讲）

我早期就踩过这个坑，测试时因为一个非常小的浮点误差导致测试间歇性失败，排查了很久。

字符串比较：

EXPECT_STREQ(str1, str2); // C风格字符串，区分大小写 EXPECT_STRNE(str1, str2); EXPECT_STRCASEEQ(str1, str2); // 不区分大小写 EXPECT_STRCASENE(str1, str2);

异常检查：

EXPECT_THROW(statement, exception_type); // 期望抛出特定类型异常 EXPECT_ANY_THROW(statement); // 期望抛出任何异常 EXPECT_NO_THROW(statement); // 期望不抛异常

3.2 测试夹具（Test Fixture）：管理测试的共享环境

当多个测试用例需要相同的设置和清理步骤时，比如都需要创建一个数据库连接、初始化一个复杂的对象、或者准备一批测试数据，重复写这些代码会很冗余。这时就需要测试夹具。

创建一个夹具很简单，继承::testing::Test类，然后在类里重写SetUp()和TearDown()方法（类似于构造函数和析构函数，但专为测试生命周期设计）。

// 测试一个简单的“计数器”类 class Counter { public: void Increment() { value_++; } void Decrement() { if (value_ > 0) value_--; } int GetValue() const { return value_; } void Reset() { value_ = 0; } private: int value_ = 0; }; // 定义测试夹具 class CounterTest : public ::testing::Test { protected: void SetUp() override { // 每个测试开始前都会运行 counter.Reset(); // 确保每个测试起点一致 counter.Increment(); // 假设我们想从一个非零状态开始测试 } void TearDown() override { // 每个测试结束后都会运行，如果需要清理资源的话 } // 所有测试用例都可以访问的成员 Counter counter; }; // 使用 TEST_F 宏，而不是 TEST。F 代表 Fixture。 TEST_F(CounterTest, Increment_IncreasesValue) { // 此时counter已经经过SetUp()，value_为1 counter.Increment(); EXPECT_EQ(counter.GetValue(), 2); } TEST_F(CounterTest, Decrement_FromPositive) { // 同样，初始value_为1 counter.Decrement(); EXPECT_EQ(counter.GetValue(), 0); } TEST_F(CounterTest, Decrement_DoesNotGoBelowZero) { // 初始value_为1，减一次到0 counter.Decrement(); EXPECT_EQ(counter.GetValue(), 0); // 再减一次，应该还是0（根据我们的实现） counter.Decrement(); EXPECT_EQ(counter.GetValue(), 0); // 测试边界行为 }

使用TEST_F时，你可以在测试体内直接使用夹具类中定义的成员变量（如counter）。SetUp()保证了每个测试的独立性，这是单元测试的黄金法则之一：测试之间不应该有依赖。即使前一个测试把counter改得一塌糊涂，下一个测试开始时，SetUp()会重新初始化它。

3.3 参数化测试：避免重复代码的利器

想象一下，你要测试一个判断数字是否为偶数的函数IsEven(int n)。你需要测试很多组输入输出：(2, true),(3, false),(0, true),(-2, true),(-3, false)……如果为每一组都写一个TEST，代码会非常臃肿。参数化测试就是为了解决这个问题。

// 1. 定义一个参数化测试类，同样继承自 ::testing::TestWithParam class IsEvenTest : public ::testing::TestWithParam<std::tuple<int, bool>> { }; // 2. 使用 TEST_P 宏定义测试（P代表Parameterized） TEST_P(IsEvenTest, HandlesVariousInputs) { // 通过 GetParam() 获取参数 int input = std::get<0>(GetParam()); bool expected = std::get<1>(GetParam()); // 假设我们有这个函数 // bool IsEven(int n) { return n % 2 == 0; } EXPECT_EQ(IsEven(input), expected); } // 3. 实例化测试用例，并提供参数生成器 INSTANTIATE_TEST_SUITE_P( EvenOddTests, // 实例名称，可随意 IsEvenTest, // 测试类名 ::testing::Values( // 参数生成器，这里用Values直接列举 std::make_tuple(2, true), std::make_tuple(3, false), std::make_tuple(0, true), std::make_tuple(-2, true), std::make_tuple(-3, false) ) );

运行测试时，INSTANTIATE_TEST_SUITE_P会生成5个独立的测试点，每个点对应一组参数。输出中你会看到类似EvenOddTests/IsEvenTest.HandlesVariousInputs/0,/1这样的测试名，其中数字代表参数索引。这极大地提升了测试的覆盖率和代码的简洁性。gtest还支持更复杂的参数生成方式，如Range（范围）、Combine（组合）、ValuesIn（从容器取值）等，足以应对绝大多数数据驱动的测试场景。

4. 高级特性与实战技巧

掌握了基础，我们来看看那些能让测试变得更强大、更高效的高级特性。

4.1 模拟（Mocking）与gmock简介

单元测试的核心是“单元”，即尽可能孤立地测试一个模块。但如果你的函数依赖了一个复杂的、不可控的、或者运行缓慢的外部组件（比如数据库、网络服务、文件系统），怎么办？这时候就需要“模拟”（Mock）——创建一个该组件的替身，在测试中控制它的行为，让它返回我们预设的值或模拟特定的异常。

gtest配套的模拟框架叫Google Mock (gmock)。它通常和gtest一起发布。使用CMake的FetchContent时，GTest::gtest_main目标实际上已经包含了gmock。gmock允许你定义一个模拟类，并指定其方法被调用时的行为。

假设我们有一个HttpClient接口，我们的业务类DataFetcher依赖它：

// http_client.h class HttpClient { public: virtual ~HttpClient() = default; virtual std::string Get(const std::string& url) = 0; // 纯虚函数 }; // data_fetcher.h class DataFetcher { public: DataFetcher(HttpClient* client) : client_(client) {} bool FetchData() { std::string response = client_->Get(“http://api.example.com/data”); return !response.empty(); } private: HttpClient* client_; };

在测试DataFetcher时，我们不应该真的发起网络请求。我们可以用gmock创建一个MockHttpClient：

#include “gmock/gmock.h” #include “gtest/gtest.h” #include “http_client.h” #include “data_fetcher.h” // 定义Mock类 class MockHttpClient : public HttpClient { public: MOCK_METHOD(std::string, Get, (const std::string& url), (override)); }; TEST(DataFetcherTest, FetchData_SuccessOnNonEmptyResponse) { // 1. 创建Mock对象 MockHttpClient mock_client; // 2. 创建被测试对象，注入Mock DataFetcher fetcher(&mock_client); // 3. 设置期望（Expectation） // 当Get方法被调用，且参数是特定URL时，返回“OK” EXPECT_CALL(mock_client, Get(“http://api.example.com/data”)) .WillOnce(::testing::Return(“OK”)); // 指定一次调用的行为 // 4. 执行测试 bool result = fetcher.FetchData(); // 5. 验证结果和行为 EXPECT_TRUE(result); // gmock会在Mock对象析构时自动验证所有期望是否被满足 // 即验证了Get方法确实被调用了一次 } TEST(DataFetcherTest, FetchData_FailsOnEmptyResponse) { MockHttpClient mock_client; DataFetcher fetcher(&mock_client); EXPECT_CALL(mock_client, Get(“http://api.example.com/data”)) .WillOnce(::testing::Return(“”)); // 模拟返回空字符串 bool result = fetcher.FetchData(); EXPECT_FALSE(result); // 期望失败 }

MOCK_METHOD宏用于声明模拟方法。EXPECT_CALL是gmock的核心，它设置了我们对模拟方法调用的期望：它会被调用多少次（Times），以什么参数调用（With），以及调用时做什么（WillOnce,WillRepeatedly）。这让你能精确地测试函数在依赖对象返回各种情况下的行为，是编写高质量、高隔离度单元测试的关键。

4.2 死亡测试（Death Tests）

有些代码在特定条件下（比如非法参数、断言失败）就应该崩溃或主动调用std::terminate。如何测试这种“预期中的崩溃”呢？gtest提供了死亡测试。

// 一个不安全的除零函数（仅用于演示） int Divide(int a, int b) { if (b == 0) { std::cerr << “Divisor cannot be zero!” << std::endl; std::abort(); // 或 exit(EXIT_FAILURE); } return a / b; } TEST(DivideTest, DeathOnDivideByZero) { // 断言：执行给定的语句会导致程序以非零状态退出 EXPECT_DEATH({ Divide(10, 0); }, “Divisor cannot be zero!”); // 第二个参数是可选的正则表达式，匹配死亡前的stderr输出 }

死亡测试会fork一个新的进程来运行测试语句，因此不会导致整个测试程序崩溃。这在测试一些健壮性要求极高的代码（如库的输入验证）时非常有用。

4.3 测试事件监听器与定制输出

gtest提供了丰富的事件监听器（TestEventListener）接口，允许你定制测试运行的生命周期钩子。比如，你想在每个测试失败时，自动截取屏幕截图（对于GUI测试）或者打印出额外的调试信息；或者生成一个XML或JSON格式的测试报告给CI系统集成。

一个简单的例子，在控制台输出更简洁的信息：

#include “gtest/gtest.h” class MinimalistPrinter : public ::testing::EmptyTestEventListener { // 在每个测试用例开始前调用 void OnTestStart(const ::testing::TestInfo& test_info) override { printf(“*** Test %s.%s starting.\n”, test_info.test_suite_name(), test_info.name()); } // 在每个测试用例成功后调用 void OnTestEnd(const ::testing::TestInfo& test_info) override { printf(“*** Test %s.%s ended.\n”, test_info.test_suite_name(), test_info.name()); } }; int main(int argc, char **argv) { ::testing::InitGoogleTest(&argc, argv); // 获取全局的事件监听器列表 ::testing::TestEventListeners& listeners = ::testing::UnitTest::GetInstance()->listeners(); // 删除默认的结果打印器，添加我们自己的 delete listeners.Release(listeners.default_result_printer()); listeners.Append(new MinimalistPrinter); return RUN_ALL_TESTS(); }

你可以把这段main函数放在一个单独的测试主文件中，然后链接gtest_main库时不要链接gtest_main，而是链接gtest，并编译你自己的main文件。这给了你极大的灵活性。

5. 工程化实践与常见问题排查

把测试写出来只是第一步，如何把它用好、集成到真实的开发流程中，才是发挥其价值的关键。

5.1 测试代码的组织与管理

在大型项目中，测试代码的组织至关重要。我推荐以下结构：

project_root/ ├── CMakeLists.txt ├── include/ # 公共头文件 ├── src/ # 源代码 │ ├── module_a/ │ └── module_b/ └── tests/ # 测试代码 ├── unit/ # 单元测试 │ ├── module_a/ │ │ ├── test_algorithm.cpp │ │ └── CMakeLists.txt (可选，子目录CMake) │ └── module_b/ ├── integration/ # 集成测试 ├── mocks/ # 模拟类定义 └── main.cpp # 自定义的测试主程序（如果需要）

原则：

测试与被测代码对应：tests/unit/module_a/下的测试对应src/module_a/下的源码。这让人一目了然。
分离单元测试与集成测试：单元测试应该快速、独立、不依赖外部环境。集成测试可以依赖数据库、网络等。分开它们便于单独运行。
使用独立的main函数：对于复杂项目，建议在tests/下编写自己的main.cpp，以便统一初始化全局资源、安装自定义监听器、或处理特定平台的设置。

5.2 与构建系统和CI/CD集成

CMake集成：如前所述，使用gtest_discover_tests是现代化CMake的最佳实践。它会在构建时分析测试可执行文件，自动将所有测试用例注册为CMake的测试目标。之后你可以：

ctest：运行所有测试。
ctest -R TestMath：运行名称匹配TestMath的测试。
ctest --output-on-failure：测试失败时打印详细信息。
ctest -T memcheck（配合Valgrind等工具）：进行内存检查。

CI/CD流水线：在你的CI脚本（如GitLab CI.gitlab-ci.yml或 GitHub Actions.github/workflows/test.yml）中，添加测试步骤是标准操作。

# GitHub Actions 示例片段 - name: Configure and Build run: | cmake -B build -S . cmake --build build - name: Run Tests run: | cd build && ctest --output-on-failure

这确保了每次代码提交或合并请求都会自动运行测试套件，守护代码质量。

5.3 常见问题与排查技巧实录

即使按照指南操作，在实际项目中你仍可能遇到各种问题。这里记录几个我踩过的坑和解决方法。

问题1：链接错误 - “undefined reference to `testing::internal::...”

现象：编译测试代码时，报一堆gtest内部的函数找不到。
原因：这是最常见的错误。你的测试文件（.cpp）没有正确链接gtest库。
排查：
1. 检查CMakeLists.txt中的target_link_libraries，确保你的测试目标链接了GTest::gtest（或GTest::gtest_main，如果你用了它的默认main函数）。
2. 如果你是自己编译gtest源码，确保add_subdirectory或find_package的路径正确，并且gtest和gtest_main目标被正确定义。
3. 确保编译测试文件的CMakeLists.txt和编译gtest库的是在同一个CMake作用域内。

问题2：测试通过，但Valgrind报告内存泄漏

现象：ctest全部通过，但用ctest -T memcheck或手动运行valgrind ./your_test发现有内存泄漏，源头指向gtest内部。
原因：gtest在某些情况下（比如使用EXPECT_DEATH）会动态分配内存，并且它有一个设计决策：在程序结束时并不清理所有内部全局状态，以避免在静态对象析构顺序上出现问题。这会被Valgrind误报为泄漏。
解决：这不是你代码的泄漏。你可以通过设置环境变量来抑制这些误报。创建一个valgrind.supp文件，内容可以参考gtest源码中的googletest/scripts/valgrind_test.sh。运行Valgrind时加上--suppressions=valgrind.supp参数。更简单的方法是，对于gtest相关的“泄漏”，只要不是在你自己的业务代码中，可以暂时忽略，或者使用Google Test自带的--gtest_catch_exceptions=0选项有时也能避免。

问题3：测试运行缓慢，尤其是涉及文件/数据库的

现象：单元测试跑一次要几分钟甚至更久。
原因：单元测试不应该慢。慢通常意味着测试不是真正的“单元”测试，它们可能启动了沉重的数据库、进行了网络调用、或者频繁读写磁盘。
优化：
1. 使用Mock：这是根本解决方法。用gmock模拟所有慢速或外部依赖。
2. 使用内存数据库或临时文件：对于集成测试，如果必须用真实组件，考虑使用SQLite内存数据库、或在SetUp中创建临时文件TearDown中删除。
3. 并行运行测试：gtest支持--gtest_filter来过滤测试，但更有效的是利用CTest的-j选项并行运行测试：ctest -j 8。确保你的测试是独立的，没有共享全局状态（如全局变量、静态变量），否则并行会出问题。

问题4：如何调试一个失败的测试？

标准流程：
1. 看错误信息：gtest的错误信息非常详细，会指出哪个EXPECT_EQ失败了，预期值是什么，实际值是什么。这是第一手资料。
2. 使用--gtest_filter：如果测试很多，只运行失败的测试。例如：./run_unit_tests --gtest_filter=*DeathOnDivideByZero*。
3. 使用--gtest_repeat和--gtest_break_on_failure：对于偶发失败（Flaky Test），可以用--gtest_repeat=1000重复运行千次，看失败频率。结合--gtest_break_on_failure可以在第一次失败时进入调试器（如果支持）。
4. 使用SCOPED_TRACE：在复杂的测试逻辑中，如果失败点在一个循环或条件分支里，你可能不知道是哪个迭代或分支出了问题。可以在关键位置添加SCOPED_TRACE(“Iteration i=” + std::to_string(i));，它会将这段信息添加到后续所有断言失败的消息中。
5. 输出调试信息：在测试中临时使用std::cout或printf输出变量状态。虽然不优雅，但简单有效。记得测试稳定后要清理这些调试输出。

问题5：测试代码本身变得臃肿复杂

现象：为了测试一个函数，需要构造极其复杂的对象图，测试代码比生产代码还长。
反思：这通常是一个设计信号——你的生产代码耦合度太高了。一个函数如果依赖了太多东西以至于难以测试，它很可能违反了“单一职责原则”。
重构建议：考虑将被测函数依赖的部分提取为接口（抽象类），然后在测试中传入Mock对象。这不仅能简化测试，还能让生产代码更灵活、更符合设计原则。测试是代码设计的试金石，难以测试的代码往往也是难以维护的代码。

将gtest融入你的C++开发日常，开始时可能会觉得多写了不少代码，但长期来看，它带来的信心和效率提升是巨大的。每次修改代码后，那一声清脆的[ PASSED ]，就是对你工作最好的肯定。从今天开始，为你下一个C++模块写上几个测试用例吧，你会发现，编程的乐趣不仅在于创造，也在于这种确定性的守护。

查看全文

http://www.jsqmd.com/news/1178812/