1. 为什么我们需要单元测试？
第一次接触单元测试这个概念时，我正面临一个典型困境：修改了一个看似简单的bug，结果导致其他三个功能莫名其妙地崩溃。这种"修复一个bug引入更多bug"的恶性循环，在缺乏单元测试的项目中几乎不可避免。单元测试就像给代码穿上防弹衣，而gtest则是Google为我们打造的一套精良装备。
单元测试的核心价值在于它能将问题扼杀在摇篮里。想象你正在开发一个计算器应用，当你在凌晨三点修改了加法运算的实现后，第二天早上发现减法功能突然失灵了。有了单元测试，这种噩梦就不会发生——每次代码变更后，只需运行测试套件，几分钟内就能确认所有基础功能是否依然正常。
2. gtest环境搭建全攻略
2.1 跨平台安装指南
在Ubuntu上安装gtest简直不能更简单：
bash复制sudo apt-get install libgtest-dev
但如果你以为这就完事了，那就太天真了。实际使用时还需要手动编译：
bash复制cd /usr/src/gtest
sudo cmake CMakeLists.txt
sudo make
sudo cp *.a /usr/lib
Windows用户推荐使用vcpkg：
bash复制vcpkg install gtest
注意：很多教程会教你直接clone GoogleTest源码，但对于新手我强烈建议使用包管理器。手动编译可能会遇到各种编译器兼容性问题，特别是Windows平台。
2.2 CMake集成实战
现代C++项目基本都使用CMake，这是我最推荐的集成方式：
cmake复制find_package(GTest REQUIRED)
include_directories(${GTEST_INCLUDE_DIRS})
add_executable(MyTests test.cpp)
target_link_libraries(MyTests ${GTEST_LIBRARIES} pthread)
这里有个坑：在Linux上必须链接pthread，否则会报奇怪的链接错误。这个细节很少有教程会提到，我当初花了两个小时才找到原因。
3. 第一个测试用例解剖
3.1 TEST宏的魔法
让我们从一个最简单的测试开始：
cpp复制TEST(CalculatorTest, AddTwoNumbers) {
EXPECT_EQ(3, Add(1, 2));
}
这个看似简单的宏背后隐藏着精妙的设计：
CalculatorTest是测试套件名称，相当于测试的分类AddTwoNumbers是具体的测试用例名称EXPECT_EQ是断言宏，这里判断Add(1,2)的结果是否等于3
经验之谈：测试命名要像写文档一样认真。好的测试名应该能直接表达测试意图，比如"DivideByZeroThrowsException"就比"Test1"强百倍。
3.2 断言的艺术
gtest提供了丰富的断言宏，最常用的有：
| 断言类型 | 示例 | 适用场景 |
|---|---|---|
| EXPECT_EQ | EXPECT_EQ(3, result) | 验证相等 |
| EXPECT_TRUE | EXPECT_TRUE(IsValid()) | 验证布尔值 |
| EXPECT_NEAR | EXPECT_NEAR(3.14, pi, 0.01) | 浮点数近似比较 |
| EXPECT_THROW | EXPECT_THROW(Foo(), Exception) | 验证异常 |
特别注意浮点数比较必须用EXPECT_NEAR，直接使用EXPECT_EQ比较浮点数是个常见错误，会导致测试不稳定。
4. 测试固件(Test Fixture)进阶
4.1 为什么需要测试固件
当多个测试需要相同的初始化代码时，复制粘贴显然不是好主意。这时就该测试固件登场了：
cpp复制class DatabaseTest : public ::testing::Test {
protected:
void SetUp() override {
db = new Database(":memory:");
db->createTables();
}
void TearDown() override {
delete db;
}
Database* db;
};
TEST_F(DatabaseTest, InsertRecord) {
EXPECT_TRUE(db->insert("data"));
}
TEST_F中的F就代表Fixture。每个TEST_F都会创建一个新的Fixture实例，确保测试隔离。
4.2 固件的生命周期
- 构造Fixture对象
- 调用SetUp()
- 运行测试体
- 调用TearDown()
- 析构Fixture对象
这个顺序非常重要。我曾经在TearDown中忘记释放资源，导致内存泄漏，而Valgrind等工具很难发现测试代码中的这类问题。
5. 参数化测试实战
5.1 告别重复代码
当需要测试同一接口的不同输入时，参数化测试是救星：
cpp复制class PrimeTest : public ::testing::TestWithParam<int> {};
TEST_P(PrimeTest, IsPrime) {
int n = GetParam();
EXPECT_TRUE(IsPrime(n));
}
INSTANTIATE_TEST_SUITE_P(Primes, PrimeTest,
::testing::Values(2, 3, 5, 7, 11));
5.2 组合参数技巧
更复杂的场景可以使用Combine：
cpp复制INSTANTIATE_TEST_SUITE_P(Matrix, MyTest,
::testing::Combine(
::testing::Values(1, 2, 3),
::testing::Values("a", "b")
));
获取参数时使用std::tie：
cpp复制int n; std::string s;
std::tie(n, s) = GetParam();
6. 测试覆盖率与持续集成
6.1 gcov集成
测试写了但没执行到关键代码？gcov来帮忙：
bash复制g++ --coverage -fprofile-arcs -ftest-coverage test.cpp
./a.out
gcov test.cpp
这会生成详细的覆盖率报告，显示哪些代码行被测试覆盖了。
6.2 CI集成示例
在GitHub Actions中配置gtest：
yaml复制jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- run: sudo apt-get install libgtest-dev
- run: |
cd /usr/src/gtest
sudo cmake CMakeLists.txt
sudo make
sudo cp *.a /usr/lib
- run: mkdir build && cd build && cmake .. && make
- run: ./MyTests
7. 常见陷阱与最佳实践
7.1 测试的黄金法则
- 独立性：测试之间不能有依赖关系
- 可重复性：在任何环境都能得到相同结果
- 原子性：一个测试只验证一件事
- 速度：整个测试套件应该在合理时间内完成
违反这些原则的测试迟早会变成维护噩梦。
7.2 测试替身(Test Doubles)
当被测代码依赖外部资源时，使用模拟对象：
cpp复制class MockDatabase : public DatabaseInterface {
public:
MOCK_METHOD(bool, connect, (const std::string&), (override));
};
TEST(DatabaseTest, ConnectionTest) {
MockDatabase db;
EXPECT_CALL(db, connect("test.db"))
.WillOnce(Return(true));
Client client(&db);
EXPECT_TRUE(client.start());
}
Google Mock与gtest无缝集成，是处理依赖的利器。
7.3 测试私有成员
测试私有成员是个有争议的话题。我的建议是：
- 优先通过公有接口测试
- 必要时使用friend class
- 万不得已才考虑#define private public这种hack
记住：过度测试实现细节会导致测试变得脆弱，任何内部改动都会导致测试失败。
8. 从单元测试到TDD
当你熟悉gtest后，可以尝试测试驱动开发(TDD)：
- 写一个失败测试
- 实现最简代码使测试通过
- 重构代码
- 重复
这种开发方式能显著提高代码质量。我个人的经验是，采用TDD的项目比后期补测试的项目bug少得多。
最后分享一个实用技巧：在CMake中设置CTEST_OUTPUT_ON_FAILURE=1环境变量，这样测试失败时会直接打印详细信息，不用再去翻日志文件了。