直接用 GTest 而不是手写断言，因为 GTest 提供统一的断言宏（如 EXPECT_EQ）、自动失败信息、测试组织框架及可扩展性，避免手写 assert 或 if 语句导致的冗余、无上下文错误提示和维护困难。
为什么直接用 GTest 而不是自己写断言
因为手写 assert 或 if (x != y) { cout 会快速失控：没有统一的测试发现机制、无法统计通过率、不支持测试套件分组、失败时堆栈不清晰，且 assert 在 NDEBUG 下直接消失。而 GTest 提供了 EXPECT_EQ、ASSERT_TRUE 等带上下文输出的断言，失败时自动打印实际值、预期值和文件行号，还能通过 --gtest_filter=MyTest.* 精确运行子集。
GTest 测试用例的基本结构怎么写
每个测试用例必须属于一个测试套件（test suite），由 TEST 宏定义，参数是套件名和测试名（均为合法标识符，不能含空格或点）。测试体内部用 EXPECT_*（失败继续执行）或 ASSERT_*（失败立即返回）进行校验：
#includeTEST(StringTest, EmptyStringLength) { std::string s; EXPECT_EQ(0, s.length()); // 推荐：即使失败也跑完所有断言 } TEST(StringTest, NonEmptyStringLength) { std::string s = "hello"; ASSERT_FALSE(s.empty()); // 关键前置检查，失败则跳过后续 EXPECT_EQ(5, s.length()); }
- 套件名建议按被测模块命名（如
VectorTest、JsonParserTest），便于归类 - 测试名应描述行为而非实现，例如
PushBack_IncreasesSizeByOne比TestPush更明确 - 避免在测试中使用
std::cout或printf输出调试信息；改用SCOPED_TRACE("msg")添加上下文
链接 libgtest 时常见的链接错误怎么解
最典型的是 undefined reference to testing::UnitTest::GetInstance() 或一堆 testing::internal::* 符号未定义——这说明只链接了你的测试目标，没链接 libgtest（或静态库未正确编译为与你的项目相同 ABI，比如你用了 -std=c++17 编译项目，但 libgtest.a 是用 c++11 编译的）。
- 用 CMake 时，优先走
find_package(GTest REQUIRED)+target_link_libraries(my_test PRIVATE GTest::gtest GTest::gtest_main)，它会自动处理编译选项对齐 - 手动 g++ 编译需确保
gtest和你的测试代码用相同标准：g++ -std=c++17 -I/path/to/gtest/include test.cpp /path/to/libgtest.a -o test - Windows 下若用 MSVC，注意
/MD（动态 CRT）和/MT（静态 CRT）必须与gtest库一致，否则报LNK2038
如何测试私有成员或内部逻辑
GTest 本身不提供访问私有成员的能力，也不鼓励打破封装。真实场景中应优先测试公有接口的行为表现（黑盒），比如调用 class A::process() 后检查其输出或副作用。只有极少数情况需要白盒验证，此时可：
立即学习“C++免费学习笔记（深入）”；
- 将测试文件声明为被测类的
friend（仅限头文件中定义简单逻辑的类，慎用） - 在类头中用
#ifdef TEST_BUILD暴露关键内部函数（需在构建系统中为测试目标定义该宏） - 更推荐的做法：把核心算法抽成独立的
namespace函数（如detail::validate_checksum()），它天然可测试，且不破坏封装
强行测试私有细节会让测试随实现抖动，反而降低长期可维护性。重点始终是“它是否做对了事”，而不是“它是不是用这个字段做的”。
