google test 是主流c++单元测试框架，推荐以子模块方式集成；test宏定义测试用例，expect_eq用于值比较，浮点数需用expect_float_eq；assert_*失败立即返回，运行时可用--gtest_filter等参数控制。
Google Test 是 C++ 项目中最主流、最稳定的单元测试框架，它不依赖 STL 的特定实现，支持 Windows/Linux/macOS，且与 CMake 集成顺畅。只要你的编译器支持 C++11（GCC 4.8+ / Clang 3.3+ / MSVC 2015+），就能直接用。
怎么把 Google Test 编译进你的项目
最稳妥的方式是作为子模块引入并由 CMake 构建，避免二进制兼容性问题。不要用系统包管理器（如 apt install libgtest-dev）安装，那些头文件和库常不匹配，undefined reference to testing::UnitTest::GetInstance() 就是典型症状。
- 在项目根目录执行：
git submodule add https://github.com/google/googletest.git third_party/googletest
- 确保
CMakeLists.txt中启用测试并包含子模块：enable_testing() add_subdirectory(third_party/googletest) # 然后链接到你的测试可执行文件 target_link_libraries(your_test_executable gtest gtest_main)
- 禁止定义
GTEST_LINKED_AS_SHARED_LIBRARY—— 默认静态链接更安全，否则容易遇到GLIBCXX_3.4.26 not found这类符号版本错误
如何写第一个 TEST 宏和 EXPECT_EQ 断言
TEST 是宏，不是函数，它会自动生成测试用例类和注册逻辑。所有断言都以 EXPECT_* 或 ASSERT_* 开头，前者失败继续执行，后者失败立即返回（适合前置条件检查）。
-
EXPECT_EQ比较两个值，底层调用operator==，对std::string、int、double都适用；但对自定义类型需重载operator==，否则编译报错no match for 'operator==' - 浮点数必须用
EXPECT_FLOAT_EQ或EXPECT_NEAR(val, expected, abs_error)，直接用EXPECT_EQ会因精度丢失恒失败 - 示例：
TEST(MathTest, SumReturnsCorrectValue) { EXPECT_EQ(Add(2, 3), 5); EXPECT_FLOAT_EQ(Sqrt(4.0f), 2.0f); EXPECT_NEAR(0.1f + 0.2f, 0.3f, 1e-6f); }
为什么 ASSERT_TRUE(ptr) 后面的代码没运行
ASSERT_TRUE 是“硬断言”，内部使用 return 跳出当前测试函数。如果你看到后续断言完全没输出，大概率是因为前面的 ASSERT_* 已经退出了。
立即学习“C++免费学习笔记（深入）”；
- 常见误用场景：检查指针非空后立刻解引用 —— 应该用
ASSERT_TRUE(ptr != nullptr)，而不是EXPECT_TRUE(ptr)（因为bool(ptr)在指针为nullptr时为false，但语义不清） - 若需同时验证多个条件且允许部分失败，全部改用
EXPECT_*；若某条件不满足则整个测试无意义（比如 fixture 初始化失败），才用ASSERT_* - 注意：没有
ASSERT_NOTNULL，得写成ASSERT_TRUE(ptr != nullptr)或用ASSERT_THAT(ptr, NotNull())（需含gmock/gmock.h）
怎么运行测试并看失败堆栈
默认运行所有测试，但实际开发中几乎总是需要过滤或调试单个用例。Google Test 自带命令行参数，无需额外工具链。
- 列出所有测试名：
./your_test_executable --gtest_list_tests
- 只运行匹配
MathTest的测试：./your_test_executable --gtest_filter=*.MathTest*
- 启用颜色和详细输出（失败时自动打印源码行号）：
./your_test_executable --gtest_color=yes --gtest_print_time
- 崩溃时看不到堆栈？加
--gtest_catch_exceptions=0并配合gdb ./your_test_executable，否则异常被框架吞掉
真正麻烦的从来不是写断言，而是让测试可重复、不依赖全局状态。每个 TEST 用例默认独立运行，但如果你在 SetUpTestCase 里 malloc 了一块内存又忘了 free，或者用了 static 变量缓存结果，后续测试就可能偶然失败——这种问题不会报错，只会让你花半天怀疑人生。
