如果你还在靠预算、打印日志和一堆临时拼出来的 if 判断来验证 C++ 函数对不对，那你大概率也有过这种体会：只是改了一个排序的边界条件，结果完全不相关的模块跟着崩，排查两天才发现是回归问题。真正让我下定决心认真研究 GTest 的，就是这种“明明没碰它，它却坏了”的无力感。GTest 是 C++ 社区里相当老牌、也相当完整的单元测试框架，它帮我把“证明代码还能跑”这件事从苦力活变成了例行公事。这篇内容会从选型理由、环境搭建、核心 API、参数化测试、高级用法一直讲到我在实际工程里踩过的坑，适合正在写 C++、又还没有系统补过测试的人。
1. 为什么我最终选了 GTest：它解决的不只是“有没有断言”
1.1 靠打印日志验证代码的日子，我是怎么过的
没有测试框架之前，我最常做的事情是这样的：写一个函数，编译，跑程序，把中间变量打出来，翻到终端输出的最后几行，拿计算器对着预期值手算。如果手算结果对上了，就当它通过；如果对不上，就加几行日志继续猜。这种流程在代码量小的时候还能忍受，但一旦模块之间开始互相调用，就会被反复打脸。
你可能会说，不是有assert吗？问题是assert很多项目只在 Debug 模式下生效，Release 版本里它可能直接被剥离。更麻烦的是，assert失败时直接终止进程，生产环境里用户看到的就只是一个退出码，根本不知道是哪条业务规则出了问题。我也自己写过简单的检查宏，把两个值打印出来比较，但这类脚本式工具越散越多，最后根本没人敢改，因为根本不知道哪些检查还在用。
所以，真正的问题不是“我需要一个 assert”，而是“我需要一套能稳定收集失败信息、能组织用例、能告诉我哪一行哪一列出了什么错的机制”。这套机制就是测试框架该干的活。
1.2 GTest 和 Catch2、Doctest 放一起，我看了什么
C++ 社区里主流的测试框架还有 Catch2、Doctest、Boost.Test。把它们放一起对比过之后，我选择了 GTest。不是说其他框架不好，而是 GTest 在几个关键点上更贴合我的需求。
| 维度 | GTest | Catch2 | Doctest | Boost.Test |
|---|---|---|---|---|
| 断言丰富度 | 很高，包含值比较、布尔判断、浮点比较、字符串匹配、死亡测试 | 高，基于表达式分解 | 中高 | 高 |
| 参数化测试 | 内置TEST_P+INSTANTIATE_TEST_SUITE_P | 支持，但写法差异较大 | 支持 | 支持 |
| 死亡测试 | 内置且稳定 | 有类似能力 | 较弱 | 有 |
| CMake 集成 | 官方提供GTest::gtest、gtest_discover_tests | 需要额外写一点 | 较轻量 | 需要处理依赖 |
| 上手成本 | 中 | 低（header-only） | 最低 | 高，通常要带 Boost |
我选 GTest 的理由很实在：团队里最容易找到参考资料，报错信息在社区里几乎都能搜到现成解释；它自带死亡测试能力，对防御性编程的验证特别好用；它和 CMake、CTest 的配合相当顺滑，CI 里收集测试结果只需要几行配置。Catch2 的表达式分解写出来很漂亮，Doctest 编译速度快，但在“团队协作、老项目集成、资料密度”这几个维度上，GTest 的综合得分最高。
1.3 测试框架到底在为什么买单
有一点我想先说清楚：单元测试不是写给今天看的，是写给三个月后的你和接手你代码的人看的。GTest 的价值不在“断言”两个字本身，而在于它建立了一个高质量的反馈循环。一个用例失败，它给你文件路径、行号、期望值、实际值，甚至能继续往下跑，把同一批相关的失败全部列出来，让你一次改完而不是反复跑十遍。这个反馈速度，决定了人愿不愿意经常跑测试。
它适合验证纯逻辑、解析器、状态机、数据结构和算法模块；不适合直接去测 UI 动效、真实网络请求、长时间磁盘 IO。那些场景不是单元测试该管的，硬套 GTest 只会让测试变慢、变脆。我在后面第六章还会专门讲这个边界问题。
2. 把 GTest 请进项目：环境搭建与第一个测试用例
2.1 获取源码和最小构建方式
GTest 的引入方式有几种：系统包管理器直接安装、自己编译一份丢到 third_party、用 CMake 的FetchContent拉源码。我的建议是优先用 CMakeFetchContent，因为它能把版本锁定和项目构建直接绑到 CMakeLists 里，换机器也不会出现“忘了装开发包”的问题。
下面是一份最小的 CMake 配置：
cmake_minimum_required(VERSION 3.20) project(sample_demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) include(FetchContent) FetchContent_Declare( gtest GIT_REPOSITORY <GTest官方仓库地址> GIT_TAG v1.14.0 ) FetchContent_MakeAvailable(gtest) add_executable(sample_demo_test test.cpp) target_link_libraries(sample_demo_test PRIVATE GTest::gtest_main) include(GoogleTest) gtest_discover_tests(sample_demo_test)注意最后一行用到了GTest::gtest_main。它和GTest::gtest的区别是：gtest_main自带了一个main入口，会帮你看好初始化、注册用例、遍历执行，你不需要自己写main函数。我见过很多新人在这里卡住，一链接就报undefined reference to main，原因就是把测试文件单独编译的时候搞忘了链gtest_main。如果你确实需要自己控制main，比如测试框架要在主进程里做额外的环境初始化，那也可以手动写：
#include <gtest/gtest.h> int main(int argc, char** argv) { ::testing::InitGoogleTest(&argc, argv); return RUN_ALL_TESTS(); }多数项目用默认的gtest_main就够了，两种写法的差别不大。
2.2 第一个测试：TEST 宏和常见的 EXPECT
先从一个最简单的小函数开始。假设我写了一个整数加法函数：
int add(int a, int b) { return a + b; }对应的测试长这样：
#include <gtest/gtest.h> int add(int a, int b) { return a + b; } TEST(AddTest, PositiveInputs) { EXPECT_EQ(add(1, 2), 3); EXPECT_EQ(add(10, 20), 30); } TEST(AddTest, NegativeInputs) { EXPECT_EQ(add(-1, -2), -3); }TEST(TestSuiteName, TestName)是 GTest 最核心的组织单位。宏的第一个参数是套件名，第二个是具体的用例名。同一段代码里同名套件会被归类到一起，运行的时候按套件归组、按用例逐个报告。你别小看这个命名设计，它决定了后面所有筛选、排查和报告可读性的基础。
为什么测试用例要用宏而不是普通函数？因为宏在预处理阶段自动生成了一个类，并且通过静态注册把这个用例挂到框架的全局列表里。所以你可以把“用例”当成一种被框架自动发现的注册单元，不需要手动维护一个“所有测试函数”的数组。这也是 GTest 用起来省心的原因之一。
断言的书写习惯上，我推荐把“实际值”写在前面，“期望值”写在后面。原先是EXPECT_EQ(add(1, 2), 3)读起来就是“算出来的值应该等于 3”，失败信息里也会明确告诉你左右两边的值分别是什么。
2.3 编译、运行，以及第一次看到失败输出
假设上面的代码放在test.cpp，构建和运行的命令如下：
mkdir -p build && cd build cmake .. -DCMAKE_BUILD_TYPE=Debug cmake --build . -j4 ./sample_demo_test --gtest_filter=AddTest.*如果一切正常，你会看到类似这样的输出：
[==========] Running 2 tests from 1 test suite. [----------] Global test environment set-up. [----------] 2 tests from AddTest [ RUN ] AddTest.PositiveInputs [ OK ] AddTest.PositiveInputs (0 ms) [ RUN ] AddTest.NegativeInputs [ OK ] AddTest.NegativeInputs (0 ms) [----------] 2 tests from AddTest (0 ms total)我故意把期望值改成 99，再看一次失败输出：
[ RUN ] AddTest.PositiveInputs test.cpp:6: Failure Expected equality of these values: add(1, 2) Which is: 3 99 [ FAILED ] AddTest.PositiveInputs (0 ms)这个格式对排查特别重要。第一行告诉你文件的行号，下面两行分别展示实际值和期望值。你不需要重新打开调试器一步步看，也基本不需要加日志猜当前变量的值，框架已经替你完成了第一轮定位。这个反馈速度就是 GTest 给我的最大效率提升。
3. 核心 API 不止 TEST 宏：断言语义、套件组织与夹具复用
3.1 EXPECT_* 和 ASSERT_* 的取舍：出错后继续还是马上停
GTest 的断言大致分成两族：EXPECT_*和ASSERT_*。它们只差在一个行为上：EXPECT_*失败后，继续执行当前用例后面的语句；ASSERT_*失败后，直接终止当前用例，跳到下一条用例。
| 断言形式 | 失败后行为 | 适用场景 |
|---|---|---|
EXPECT_EQ/EXPECT_TRUE/EXPECT_FASE | 继续运行当前用例 | 想一次收集多个失败点 |
ASSERT_EQ/ASSERT_TRUE/ASSERT_FALSE | 终止当前用例 | 前置条件不成立时快速止损 |
我先给一个最容易理解的组合用法。假设测试一个解析函数，输入"a,b"，预期返回两个 token：
TEST(ParserTest, ParseSimpleInput) { auto tokens = tokenize("a,b"); ASSERT_EQ(tokens.size(), 2); EXPECT_EQ(tokens[0], "a"); EXPECT_EQ(tokens[1], "b"); }这里ASSERT_EQ(tokens.size(), 2)必须用ASSERT而不是EXPECT。如果解析函数返回的 token 数不是 2，后面的tokens[0]、tokens[1]访问就越界了。越界可能直接让进程崩溃，反而掩盖了“解析结果数量错误”这个真正原因。所以原则是：当前面的断言失败会导致后续代码无法安全执行时，统一用ASSERT_*；如果后续语句不会崩溃，只是想尽量多曝光问题，那就用EXPECT_*。
GTest 还提供了很多常用断言。EXPECT_FLOAT_EQ和EXPECT_DOUBLE_EQ专门比较浮点类型，因为浮点直接比等号很容易被精度坑；EXPECT_NEAR(val, expected, abs_error)可以指定一个绝对误差范围。另外EXPECT_THAT配合内置的 matcher（比如::testing::HasSubstr、::testing::StartsWith）在测字符串和容器时非常顺手：
EXPECT_THAT(error_message, ::testing::HasSubstr("timeout"));3.2 套件组织：把测试当文档写
测试代码写得像不像文档，很大程度取决于命名。GTest 的推荐习惯是：套件名用模块名或类名，用例名用“行为 + 场景”。比如说，一个 LRU 缓存，你想要的用例名是LruCacheTest.EvictsOldestWhenFull、LruCacheTest.RefreshesLruOrderOnGet，而不是Test1.f1、Test2.f2。
为什么这么重要？因为 GTest 支持--gtest_filter筛选。你调试某个行为时，只需要执行这一条用例，比如：
./sample_demo_test --gtest_filter=LruCacheTest.EvictsOldestWhenFull如果测试命名混乱，筛选等于没有。而且一组好的用例名本身就是一份可执行的规格说明，新人接手代码时先跑一遍列表，就能大概知道这个模块支持哪些行为。这个“测试作为可执行文档”的好处，用久了才能体会到。
3.3 数据准备：用 TEST_F 减少重复
当很多用例都需要准备同一个对象时，最蠢的办法是在每个TEST里都写一遍初始化代码。GTest 的TEST_F（F 表示 Fixture，夹具）解决的就是这个问题。先定义一个继承自::testing::Test的夹具类，在SetUp里做初始化，然后所有用例共用这套布置。
class StackFixture : public ::testing::Test { protected: void SetUp() override { st.push(1); st.push(2); } void TearDown() override {} MyStack st; }; TEST_F(StackFixture, PopReturnsTop) { EXPECT_EQ(st.pop(), 2); } TEST_F(StackFixture, SizeDecreasesAfterPop) { st.pop(); EXPECT_EQ(st.size(), 1); }关键点在于：每个TEST_F用例在运行之前，框架都会重新创建一个新的夹具对象，然后调用一次SetUp；用例结束之后再调用TearDown，最后析构。也就是说，两个用例之间虽然看起来共享同一个变量st，但它们各自操作的是不同的实例，底层状态是隔离的。这个设计保证了用例之间不会互相污染，也是 GTest 稳定性的基础。
很多人刚接触时容易搞错一件事：以为可以在SetUp里准备一个大全局对象，然后所有用例共享它修改。这是反模式。夹具的设计初衷是每个用例独立，不是跨用例的全局仓库。如果你真的需要很重的初始化，比如加载一个大文件，请考虑用SetUpTestSuite（也叫SetUpTestCase，旧版本名称），它只在整个测试套件开始前执行一次，但我个人建议慎用，因为一旦在用例之间共享可变状态，又得小心顺序污染问题了。
4. 参数化测试：一杯数据喂饱所有分支
4.1 为什么别在 TEST 里写 for 循环
初学者最容易踩的坑之一，就是在一条TEST里塞一个 for 循环，遍历各种数据然后断言。比如：
TEST(SquareTest, AllValues) { for (const auto& data : test_values) { EXPECT_DOUBLE_EQ(square(data.first), data.second); } }这种写法最难受的一点是：一旦循环中某个参数失败，失败信息只指向同一个文件、同一行，你根本看不出来是循环里的第几个数据出了问题。尤其是在EXPECT不会中断循环的情况下，后续的脏数据也会跟着一起报错，输出一大片“看起来全是同一个位置”的失败记录，排查效率非常低。而且这种写法没有办法针对单个参数做筛选、跳过和单独运行。
参数化测试就是为解决这个问题设计的：把“输入数据”从代码里抽出来，让框架为每一组数据生成一个独立用例。
4.2 TEST_P 和 INSTANTIATE_TEST_SUITE_P 的用法
参数化测试需要两个步骤。第一步，定义一个继承自::testing::TestWithParam<T>的类，T就是每组参数的类型；第二步，用TEST_P写用例体，用GetParam()拿到当前这组参数；最后用INSTANTIATE_TEST_SUITE_P把所有参数实例化。
举个例子。假设我要测试一个平方函数double square(double x)，使用std::pair<double, double>作为参数类型，第一项是输入，第二项是期望输出：
class SquareTest : public ::testing::TestWithParam<std::pair<double, double>> { }; TEST_P(SquareTest, MatchesExpected) { auto [input, expected] = GetParam(); EXPECT_DOUBLE_EQ(square(input), expected); } INSTANTIATE_TEST_SUITE_P( SquareCases, SquareTest, ::testing::Values( std::make_pair(0.0, 0.0), std::make_pair(1.0, 1.0), std::make_pair(-1.0, 1.0), std::make_pair(2.5, 6.25) ));运行之后，GTest 会为每组数据生成一个独立的用例，名字大概长这样：
SquareCases/SquareTest.MatchesExpected/0 SquareCases/SquareTest.MatchesExpected/1 SquareCases/SquareTest.MatchesExpected/2 SquareCases/SquareTest.MatchesExpected/3每一组数据都有独立的编号、独立的执行记录和独立的失败报告。这样你想单独排查第 3 组数据，直接 filter 到它就行：
./sample_demo_test --gtest_filter=SquareCases/SquareTest.MatchesExpected/3如果你的 C++ 标准版本比较老，不支持结构化绑定，那就把auto [input, expected]换成：
double input = std::get<0>(GetParam()); double expected = std::get<1>(GetParam());4.3 参数化之后的可读性优化
实例化参数时，除了::testing::Values，还有几个非常实用的选择器：
::testing::Range(start, end)：生成一段连续整数，比如Range(0, 10)会生成 0 到 9。::testing::ValuesIn(container)：从一个 vector 或数组里取参数，特别适合从配置文件里读取测试数据。::testing::Combine(g1, g2, ...)：生成多个生成器的笛卡尔积，可以组合出参数组合爆炸的效果。比如同时测图片的宽、高、缩放系数，一组 Combine 就能把所有组合铺开。
参数化用例数量很大时，别怕，这是它的优势。配合--gtest_filter和--gtest_repeat=1，你完全可以只针对一组参数做调试。我自己的习惯是：能用参数化表达的分支，绝不用循环塞进单条TEST。参数化把“数据”和“行为”彻底分开，测试报告也变成了数据的可读数。
5. 更贴近真实场景的高级用法
5.1 死亡测试：验证“应该崩”的代码
正常的单元测试都希望程序别崩，但有些函数写的就是防御逻辑：入参非法时主动中断进程。比如一个解析器，传入空指针时调用abort()。这种“预期会终止”的行为，普通断言搞不定，因为你不能让它真的把整个测试进程炸掉。GTest 的死亡测试就是专门干这个的。
典型写法：
TEST(ParserDeathTest, HandlesNullInput) { ASSERT_DEATH(parse(nullptr), "null.*input"); }ASSERT_DEATH的第一个参数是会执行的那句语句，第二个参数是正则表达式，用来匹配进程退出前打印到 stderr 的错误信息。GTest 在 Linux、macOS 上会 fork 一个子进程去执行这句语句并观察退出行为，主测试进程不受影响。Windows 上的实现机制不同，正则匹配也略有差异，所以跨平台的死亡测试输出要特别留意。
这类测试的价值我很晚才体会到。它逼着你想清楚：“这个函数到底允不允许被传空？如果不允许，那么调用的后果是不是明确的？”有死亡测试兜底，后续重构时你就敢把防御逻辑改得更严格，或者引入新的检查分支。
不过要提醒一句：尽量避免在一个用例里连续写多个死亡测试，也不要让死亡测试的语句去依赖流程中产生的资源，否则资源清理很容易变成谜之问题。
5.2 当你只想跑一个用例：过滤器和运行参数
GTest 提供了很完整的命令行选项，我挑几个最常用的列一下：
| 参数 | 作用 |
|---|---|
--gtest_list_tests | 只列出所有用例，不执行 |
--gtest_filter=模式 | 筛选执行用例，支持*和?通配，前缀-表示排除 |
--gtest_repeat=N | 重复运行 N 次，适合排查偶发失败 |
--gtest_shuffle | 随机打乱执行顺序，暴露用例之间的隐式依赖 |
--gtest_random_seed=N | 指定随机种子，让随机顺序可复现 |
--gtest_break_on_failure | 断言失败时触发调试器断点，配合 IDE 特别好用 |
--gtest_output=xml:result.xml | 把测试结果导出为 XML 文件 |
--gtest_brief=1 | 只输出失败用例，正常通过的用例不再逐条打印 |
--gtest_color=yes | 强制启用彩色输出 |
我调试单个失败用例时最常用的组合是：
./sample_demo_test --gtest_filter=LruCacheTest.* --gtest_brief=1这样既能聚焦一组用例，又不会被大量“OK”刷屏。--gtest_break_on_failure在 Linux 下的传统调试器里体验一般，但在带图形界面的 IDE 里非常好用，失败那一行会直接停下来，你可以在栈上看到所有局部变量。
5.3 把结果交给 CTest / CI
项目规模一大，手动跑二进制不够干净。GTest 官方提供了 CMake 集成模块，最常见的是两种做法。
第一种是用add_test把整个测试二进制注册成一个 CTest 用例：
add_test(NAME sample_demo_test COMMAND sample_demo_test)但它的缺点很明显：一个二进制里可能有成百上千个用例，这样做失败时 CTest 只能告诉你“这个二进制的返回值非零”，定位不到具体哪条用例。
第二种更推荐，用gtest_discover_tests：
include(GoogleTest) gtest_discover_tests(sample_demo_test)它会在构建结束后自动执行一次测试二进制来枚举所有用例，然后逐个注册给 CTest。这样你在 CI 里跑ctest --output-on-failure时，能看到每一条 GTest 用例的独立结果，哪个套件、哪个参数组合失败都清清楚楚。
要留意的是，gtest_discover_tests在用例特别多、参数化组合爆炸的时候，枚举阶段会额外执行一次二进制，启动开销会被放大。这种情况下，我一般会把部分非常重的参数化用例单独拆到一个二进制里，避免每次枚举都要加载一堆无用组件。
5.4 输出格式与偶发问题的排查
GTest 的 XML 输出格式挺干净，CI 脚本可以直接解析：
./sample_demo_test --gtest_output=xml:test_result.xml这行命令会把结果写到test_result.xml，里面包含套件名、用例名、运行时间、失败信息。很多构建平台都能直接读懂这种格式，不需要再写解析脚本。
另一个值得养成的习惯是：如果你怀疑测试有偶发失败，先跑一遍随机顺序：
./sample_demo_test --gtest_shuffle --gtest_random_seed=12345 --gtest_repeat=100只要随机顺序跑出失败，基本可以断定是测试用例之间存在隐式状态依赖。这种问题平常盯着一两个用例跑是发现不了的，只有把顺序打乱才现形。等冒出问题后，用固定的随机种子复现，再逐对排查用例之间的影响。这个技巧帮我在实际项目里抓出过不止一个“离开前一个用例就跑不过”的隐藏问题。
6. 我在真实工程里踩过的坑（这部分是重点）
6.1 静态初始化顺序造成的“假失败”
我第一次在项目里批量补测试时，遇到过一个特别困惑的现象：有几个用例单独跑全绿，但是整套测试跑起来却偶尔红，而且红的位置还不固定，有时候是 A 挂，有时候是 B 挂。排查了很久，后来才发现根源是某个配置模块里的全局单例。
老代码里很常见的写法是，用一个全局对象保存配置路径和初始值，比如这样：
static Config g_config = load_config();C++ 标准对跨编译单元的静态对象初始化顺序没有保证，谁先初始化取决于链接顺序、编译器实现。当测试用例 A 和测试用例 B 分别依赖了不同的全局对象时，它们的初始化先后顺序不一样，就会产生“时好时坏”的诡异表现。
解决方向有两个：一是把static Config g_config = load_config();改成函数内静态局部变量的懒加载模式：
Config& getConfig() { static Config config = load_config(); return config; }二是如果项目里静态初始化的东西已经很多，一时改不动，就在测试main里先显式调用一遍初始化函数，把顺序固定下来。
这条经验也让我养成一个习惯：遇到“单例相关用例时好时坏”，第一反应先看静态初始化顺序，而不是先去怀疑业务逻辑。前者的问题几乎不属于算法错误，而是生命周期顺序错乱，排错的思路完全不同。
6.2 断言写在循环体里，Debug 成本反而变高
我在前面讲参数化时已经提过一次循环内断言的问题，这里用一个真实的反面案例再强调一下。假设要校验一批规则配置，最容易写的代码长这样：
TEST(ConfigTest, AllRulesValid) { for (const auto& rule : rules) { EXPECT_TRUE(validate(rule)); } }一旦某条 rule 校验失败，GTest 会在同一个文件、同一个行号上打印出失败信息，而循环又不会因为EXPECT失败而停止，于是一大片失败记录全是同一个位置，你根本不知道是列表里哪一条 rule、哪个字段出了问题。如果你还需要针对每一条规则单独跑、单独跳过，这种写法完全做不到。
我的改进建议是：这类“多条相似数据验证”的场景，优先改成参数化测试。如果数据量实在太大、参数化会导致报告爆炸，那就把断言信息手动拼进失败消息：
for (const auto& rule : rules) { EXPECT_TRUE(validate(rule)) << "rule id: " << rule.id; }GTest 的<<流式追加信息能直接把关键上下文打进失败报告，这是很多新手不知道的实用技巧。
6.3 全局状态污染：AB 两用例互相“投毒”
全局变量是 C++ 老项目的常见问题，在测试里更是重灾区。一个典型场景是：用例 A 改了一个全局的日志级别、缓存开关、环境变量，测试完没有恢复；用例 B 假设这些配置是默认值，结果跑起来就挂了。而最气人的是，这种情况经常不是必现，因为你以为用例会按代码顺序一个个跑，实际上 GTest 的执行顺序、链接顺序、filter 筛选都可能改变它。
解决这个问题的思路不是“我在测试结束后手动恢复现场”，而是要从设计上减少可变全局状态。如果测试逻辑确实绕不开全局配置，我建议在SetUp()里把所有相关状态显式重置一遍，不要把“默认值”寄托在外层调用者身上：
class ConfigDependentTest : public ::testing::Test { protected: void SetUp() override { resetConfigToDefault(); } };这个习惯看起来只是多写了一行，但能省掉你之后排查“为什么本地全绿、CI 爆红”的时间和心态成本。它也是我判断一个测试代码健不健壮的第一印象指标。
6.4 别拿单元测试当集成测试：网络、文件、线程统统不要
GTest 跑得再快，也扛不住有人把外部依赖直接塞进用例里。我见过一个项目为了测一个 CSV 解析函数，在测试文件里直接写死了绝对路径，结果代码仓库被别人挪了一个目录之后，整套测试就飘红。还有团队在单测里发起真实的 HTTP 请求，测试几秒钟才跑完一次，每次 CI 都提心吊胆地怕外网抖动。
单测的第一目标应该是“快速、稳定、可重复”。如果你的测试要访问网络、要读真实文件、要起额外线程，那它更接近集成测试或冒烟测试。我的做法是，把业务逻辑拆成两层：纯计算的函数放在内层，方便 GTest 直接测；IO、进程调度等副作用放在外层，用接口隔离，测试时传入可控的替身对象。这样既保住了覆盖度，也不会让测试变成定时炸弹。
6.5 快速上手时最容易犯的几个“小毛病”
最后把我见过的新手问题集中列一下，很多都是 CMake 层面和习惯层面的：
- 忘了链接
GTest::gtest_main，导致到处是undefined reference to main。最低成本的解法是复制我前面给出的最小 CMake 配置，先跑起来再改。 - 在
TEST_F的夹具类里把成员变量写成 static。除非你明确知道自己在做什么，否则这会破坏用例之间的隔离性。 - 参数化测试里
TestWithParam<T>的类型和INSTANTIATE_TEST_SUITE_P传入的数据类型不一致，编译报错长得像模板黑魔法，先把类型统一再看。 - 把
EXPECT和ASSERT混在一个顺序链里，后面的代码在ASSERT失败后使用了未赋值的变量。GTest 编译期不会拦你，但运行时可能莫名其妙崩。 - 测试文件和被测代码放在同一个目录，导致 include 路径混乱。建议测试单独放一个
tests/目录，构建目标也单独命名。
目录结构可以参考这个：
project/ CMakeLists.txt src/ add.cpp add.h tests/ CMakeLists.txt add_test.cpp最后补一句：补老项目测试，先从最容易烂的逻辑开始
我个人最后想补一句：如果你是从零开始给一个老项目补测试，别想着一次性把所有功能都覆盖，这个目标既宏大又不现实。更聪明的做法是先挑那些最容易变、最容易破坏的逻辑开始写，比如排序边界、解析规则、状态迁移、缓存淘汰。每补一批，就跑一次全套用例，确认没有意外变红。GTest 用顺手之后，你会发现“回归问题”不再是靠加班排查出来的事故，而是几分钟就能定位的日常检查项。这种感觉，只有真正经历过老项目无人敢改的人才会懂。
