C++单元测试实战：从框架选型到CI集成

1. 为什么C++项目需要单元测试

在C++开发领域，单元测试常常被忽视却又至关重要。我经历过多个大型C++项目，发现那些没有良好单元测试的项目，后期维护成本往往呈指数级增长。一个典型的例子是：某金融交易系统因为一个简单的边界条件未测试，导致上线后产生数百万损失。

C++作为系统级语言，其内存管理、指针操作等特性使得代码更容易出现隐蔽错误。单元测试就像是给代码装上显微镜，能在早期发现那些肉眼难以察觉的问题。与Java/Python等语言相比，C++的单元测试更具挑战性——没有虚拟机保护层，一个野指针就可能直接导致程序崩溃。

2. 主流C++测试框架选型

2.1 Google Test vs Catch2 深度对比

在最近三年的C++项目中，我交替使用过Google Test和Catch2。它们的核心差异在于：

• Google Test：更适合大型项目

  • 优点：成熟的断言系统、死亡测试、参数化测试
  • 缺点：需要编译安装，对新手不够友好
  • 典型配置：

    cmake复制find_package(GTest REQUIRED)
    target_link_libraries(my_test PRIVATE GTest::GTest GTest::Main)
    

• Catch2：更适合快速验证

  • 优点：单头文件包含，测试用例即文档
  • 缺点：大规模测试时编译速度较慢
  • 典型用法：

    cpp复制#define CATCH_CONFIG_MAIN
    #include "catch2/catch.hpp"
    

2.2 框架选型决策树

根据项目特征选择：

• 企业级长期项目 → Google Test
• 开源库/小型工具 → Catch2
• 需要极致性能测试 → doctest

经验提示：避免在同一个项目中混用多个测试框架，这会导致CI配置复杂化。

3. 实战：构建可测试的C++代码

3.1 依赖注入在C++中的应用

传统C++代码常出现紧耦合问题，比如：

cpp复制class PaymentService {
  Database* db; // 直接依赖具体实现
public: