写C++的工程师里，认真做单元测试的比例并不算高，其中一个常被提起的原因就是测试框架的搭建成本高、上手体验参差不齐。其实C++生态里已经有好几款成熟稳定的测试框架，各有鲜明的性格：有的胜在生态完善，有的胜在轻量快速，有的胜在语法优雅。选错了框架，测试代码写起来别扭，团队积极性受挫；选对了框架，测试会成为开发流程里自然而然的一环。本文从主流框架的对比入手，聊聊不同场景下该怎么选，以及在CMake工程里如何落地。
四款主流C++测试框架横向对比
C++领域最常用的测试框架基本就是Google Test（gtest）、Catch2、Boost.Test和doctest这四款。它们都能完成断言、组织测试用例、生成测试报告这些基础工作，但在设计理念和工程体验上差异明显。
Google Test是谷歌出品的框架，配合同为谷歌出品的Google Mock可以覆盖打桩需求，是目前工业界使用最广泛的组合。它的优势在于文档丰富、几乎所有CI平台都有现成支持，输出格式还能被CTest和各大IDE直接解析。缺点是编译gtest本身以及测试代码中包含其头文件的开销不小，大型项目全量编译测试时会明显感觉到慢。
Catch2走的是单头文件、无外部依赖的路线（v2版本是一个头文件，v3改成了库形式但仍然轻量），它最大的卖点是自然语言风格的测试声明和用编译期技巧自动注册测试用例的能力。写一个测试不需要定义main函数，不需要把用例塞进宏列表，直接TEST_CASE一行就能开跑，上手门槛非常低。doctest则是后起之秀，号称编译和运行速度最快的C++测试框架，API风格模仿Catch2但极致优化了编译开销，对频繁增量编译的开发流非常友好。
下表从几个关键维度做个对比：
| 维度 | Google Test | Catch2 | Boost.Test | doctest |
|---|---|---|---|---|
| 依赖 | 需编译库 | v2单头文件 | 依赖Boost | 单头文件 |
| 编译速度 | 较慢 | 中等 | 慢 | 最快 |
| Mock支持 | GMock官方配套 | 需第三方 | 无内置 | 无内置 |
| 学习曲线 | 平缓 | 最平缓 | 较陡 | 平缓 |
| 生态成熟度 | 最高 | 高 | 高 | 中等 |
不同项目场景下的选型建议
没有绝对最好的框架，只有最适合当前项目形态的框架。如果是大型工程、团队人数多、需要大量打桩模拟外部依赖，Google Test加Google Mock是稳妥选择。GMock的匹配器体系和参数期望设置非常强大，虽然写法稍显啰嗦，但表达力在所有C++测试方案里是第一梯队的。而且大团队里总有人写过gtest，新人接手成本低。
如果是中小型项目或者个人项目，追求快速搭建和愉快的书写体验，Catch2和doctest更合适。Catch2的REQUIRE断言配合CHECK可以灵活控制失败后是否继续执行，SECTION机制能在一个TEST_CASE里描述多个场景而不必写多个相似的用例，代码量显著减少。doctest在这条路线上更进一步，它甚至可以嵌入到生产代码里做自测试，编译速度优势在代码量上十万行的项目里体现得淋漓尽致。
嵌入式和资源受限环境需要特别考虑。Boost.test依赖整个Boost生态，交叉编译时如果不想引入Boost的构建复杂度，就先排除它。gtest虽然也能交叉编译，但配置相对繁琐；doctest这种零依赖方案在交叉工具链下几乎不需要额外处理，往往是嵌入式团队的首选。另外如果团队已经在用Boost全家桶，那Boost.test顺手拈来也没问题，它的fixture机制和自动注册能力其实相当完善，只是文档阅读体验一般。
在CMake工程中集成测试框架
选定框架后，落地到构建系统是绕不开的一步。现代CMake通过FetchContent让集成变得相当简单，以gtest为例，下面这段配置会自动拉取并链接：
include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG v1.14.0 ) set(gtest_force_shared_crt ON CACHE BOOL "" FORCE) FetchContent_MakeAvailable(googletest) enable_testing() add_executable(my_unit_tests test/string_utils_test.cpp test/parser_test.cpp ) target_link_libraries(my_unit_tests GTest::gtest_main)
注意gtest_main这个变体库已经提供了main函数，测试代码里不用再写。搭配enable_testing()之后，就可以在构建目录里用ctest命令批量执行测试，CI流水线里也只需要调一次ctest就能拿到汇总结果。
如果是Catch2，集成方式类似，链接Catch2::Catch2WithMain目标即可。工程规模变大后建议用gtest_discover_tests()或Catch2的配套CMake模块把每个TEST_CASE注册成独立的CTest条目，这样能精确知道哪一条用例失败，还可以配合ctest -j8并行执行，测试套件跑得慢的问题能缓解不少。
组织高质量测试代码的实践要点
框架只是工具，测试代码本身的质量才决定测试体系能否长期维护。首先善用fixture复用公共状态。gtest的TEST_F配合SetUp()和TearDown()，Catch2的fixture类或SECTION，都能避免每个用例都重复构造一堆对象。构造和析构逻辑集中在一处，接口变了也只需要改一个地方。
其次多用参数化测试处理批量数据。比如校验一个字符串切分函数，与其写十个几乎一样的TEST，不如用TEST_P加INSTANTIATE_TEST_SUITE_P把数据表和断言逻辑分开，新增一组数据只要往表里加一行：
class SplitTest : public ::testing::TestWithParam<std::pair<std::string, size_t>> {};
TEST_P(SplitTest, HandlesVariousInputs) {
auto [input, expected] = GetParam();
EXPECT_EQ(StringUtils::CountSegments(input), expected);
}
INSTANTIATE_TEST_SUITE_P(
BasicCases, SplitTest,
::testing::Values(
std::make_pair("a,b,c", 3),
std::make_pair("", 0),
std::make_pair("single", 1)
)
);
最后注意断言粒度。gtest里EXPECT_系列失败后继续执行、ASSERT_系列失败立即终止，遇到前置条件必须满足的情况（比如指针非空）用ASSERT，普通的结果校验用EXPECT，可以让一次运行暴露尽可能多的问题，减少来回跑测试的次数。
测试框架的选型不必反复纠结太久，团队达成一致后坚持写下去比选哪个更重要。先用doctest或Catch2快速起步，等项目复杂到需要重型打桩能力时再评估迁移，也是完全合理的演进路线。
C++测试框架Google TestCatch2单元测试修改时间：2026-09-10 18:34:40