移动开发跨平台前端UI组件OpenHarmony【免费下载链接】weexA framework for building Mobile cross-platform UI项目地址https://gitcode.com/gh_mirrors/we/weex点击查看免费下载本文以 Weex 仓库中随第三方依赖一并托管的 googletest 官方 FAQ 文档位于 weex_core/test/third_party/googletest/googletest/docs/faq.md为核心骨架系统梳理 googletest 在测试命名、断言宏、死亡测试、测试夹具与编译期陷阱等维度的经典疑难杂症与官方解答并结合 Weex Core 测试工程的实际接入方式CMake 构建、HelloTest测试目标、测试运行脚本做源码级印证。读完本文你将掌握 googletest 诸多隐蔽角落的正确用法能够在 Weex Core 乃至任何 C 项目中写出健壮、可维护、不易踩坑的单元测试。一、背景Weex Core 中的 googletest 与测试工程googletest 并未被 Weex 单独引入而是作为第三方测试框架随weex_core一并托管在仓库中其根目录为 weex_core/test/third_party/googletest其中包含googletest与googlemock两个子项目。从 weex_core/test/third_party/googletest/CMakeLists.txt 可以看到当前托管版本为googletest 1.9.0构建时会根据BUILD_GMOCK选项决定是否同时编译 gMock 子项目。Weex Core 的测试工程通过 CMake 组装起来链路非常清晰weex_core/test/CMakeLists.txt 定义了独立的WeexCoreTest工程要求C14标准并调用enable_testing()开启 CTest 支持随后通过add_subdirectory(third_party)与add_subdirectory(src)引入 googletest 与测试源码weex_core/test/src/CMakeLists.txt 定义了测试可执行文件HelloTest它链接的是gtest_maingoogletest 自带的带main()的库并通过add_test(WeexTests HelloTest)把该可执行文件注册为一个名为WeexTests的 CTest 测试用例weex_core/test/src/HelloTest.cpp 是现成的测试示例#include gtest/gtest.h后用TEST(WsonTest, ParseTest)包裹一个EXPECT_EQ(1, 1)断言weex_core/test/scripts/init.sh 负责在out目录下执行cmake ../完成配置weex_core/test/scripts/test.sh 进入out目录执行make test运行全部测试。也就是说TEST、TEST_F、EXPECT_*、ASSERT_*、死亡测试等本文讨论的一切概念都会直接作用于 Weex Core 的测试代码。理解 FAQ 中的这些细节等于理解了 Weex Core 测试代码的底层语法。二、命名规范为什么测试套件名与测试名不能含下划线FAQ 的第一个问题解释了 googletest 的一条硬性约定TestSuiteName与TestName中不要使用下划线_。这并非排版偏好而是 C 语言层面的强制约束。C 标准为编译器与标准库保留了以下两类标识符任何以_开头、且紧跟一个大写字母的标识符任何在名字任意位置包含两个连续下划线__的标识符。用户代码被禁止使用这类标识符。而 googletest 的TEST(TestSuiteName, TestName)宏展开后实际会生成一个名为TestSuiteName_TestName_Test的类于是下划线就会直接引爆保留字规则若TestSuiteName以_开头且后随大写字母如_Foo生成_Foo_TestName_Test非法若TestSuiteName以_结尾如Foo_生成Foo__TestName_Test含__非法若TestName以_开头如_Bar生成TestSuiteName__Bar_Test非法若TestName以_结尾如Bar_生成TestSuiteName_Bar__Test非法。严格来说TestSuiteName以_开头、只要_后不是大写字母就仍然合法但为了简单易记googletest 索性一刀切不要以_开头。即便放在名字中间也存在隐患——命名冲突。考虑TEST(Time, Flies_Like_An_Arrow) { ... } TEST(Time_Flies, Like_An_Arrow) { ... }两个TEST展开后都会生成同一个类Time_Flies_Like_An_Arrow_Test直接冲突。因此 googletest 请求用户在整个名字中完全避免_。这条规则比实际必要更严格但简单、好记也给 googletest 未来实现演进留出了空间。违反规则未必立刻出错但可能在新编译器或新版本 googletest 下悄悄失败所以最好始终遵守。对照 Weex Core 的 HelloTest.cppTEST(WsonTest, ParseTest)中WsonTest与ParseTest均不含下划线正是这一规范的实践体现。三、断言宏的语义与类型问题3.1 为什么支持EXPECT_EQ(NULL, ptr)却不支持EXPECT_NE(NULL, ptr)FAQ 解释了一个不对称设计googletest 实现了EXPECT_EQ(NULL, ptr)与ASSERT_EQ(NULL, ptr)却刻意不做EXPECT_NE(NULL, ptr)/ASSERT_NE(NULL, ptr)。首先更推荐的是EXPECT_NE(nullptr, ptr)/ASSERT_NE(nullptr, ptr)。因为nullptr是 C11 的类型安全空指针没有NULL带来的类型问题——这正是NULL版本难以支持的原因要让NULL作为EXPECT_XX()/ASSERT_XX()宏的参数需要借助相当复杂的模板元编程技巧这会让 googletest 的实现更难维护、更易出错因此只在最需要的地方提供支持。为什么EQ最需要因为EXPECT_EQ()的约定是第一个参数为期望值、第二个参数为实际值EXPECT_EQ(NULL, some_expression)是非常自然的写法也确实被多次请求所以实现了。而EXPECT_NE(NULL, ptr)的需求弱得多断言失败时你本来就知道ptr必须是NULL打印ptr并不会增加信息量EXPECT_TRUE(ptr ! NULL)完全可以替代。更深层的原因是参数顺序没有约定与EXPECT_EQ不同EXPECT_NE的两个参数没有期望值/实际值之分若支持EXPECT_NE(NULL, ptr)就必须同样支持EXPECT_NE(ptr, NULL)等于把模板元编程技巧用两遍维护成本翻倍而收益有限googletest 认为不划算。最后随着 gMock matcher 库的成长googletest 更鼓励使用统一的EXPECT_THAT(value, matcher)语法matcher 可以轻松组合出新 matcher而EXPECT_NE等宏做不到因此官方选择把投入更多放在 matcher 生态上。3.2EXPECT_EQ(htonl(blah), blah_blah)在 opt 模式下的诡异编译错误当你在优化模式下写EXPECT_EQ(htonl(blah), blah_blah)得到难以理解的编译错误时FAQ 指出bug 不在 googletest而在htonl()本身。按man htonl的说明htonl()是一个函数因此可以合法地把它当作函数指针使用。但在优化模式下htonl()被定义成了宏破坏了这种用法。更糟的是这个宏定义使用了gcc扩展并非标准 C存在一些临时性的限制——尤其会阻止你写出Foosizeof(htonl(x))()这种把sizeof放进模板整型参数的代码。而EXPECT_EQ(a, b)的实现恰恰会在模板参数内部使用sizeof(... a ...)所以在 opt 模式下当a里包含对htonl()的调用时就会编译失败。要让EXPECT_EQ绕过htonl()的 bug 非常困难因为解决方案必须在不同平台的不同编译器下都成立。FAQ 的结论是htonl()还有其他问题相关头文件定义了ghtonl()作为替代——它做同样的事但没有这些问题建议在测试代码和产品代码中都使用ghtonl()替代htonl()同理还有ghtons()替代htons()。使用这些替代函数时记得把对应的依赖加入BUILD文件该库只有一个头文件不会让二进制变大。3.3 用户自定义类型报 no match for operator如果你在断言中使用自定义类型FooType编译器可能抱怨找不到运算符。原因是断言失败时 googletest 需要把参数值打印出来因此必须存在std::ostream operator(std::ostream, const FooType)另外有一个非常隐蔽的规则如果FooType声明在某个命名空间中那么这个运算符也必须定义在同一个命名空间中否则同样无法被找到这与 ADL 参数依赖查找的机制相关。四、接口实现的共性测试typed tests 还是 value-parameterized tests当需要验证同一个接口的不同实现是否满足共同需求时googletest 提供两种方案类型参数化测试typed tests如TYPED_TEST和值参数化测试value-parameterized tests如TEST_P。FAQ 给出的取舍指南非常实用typed tests 更易写的场景不同实现的实例可以用同样方式创建、只是类型不同。例如所有实现都有公开默认构造函数可以直接new TypeParam或者它们的工厂函数形式一致如CreateInstanceTypeParam()。value-parameterized tests 更易写的场景不同实现的实例需要不同的创建代码例如new Foo与new Bar(5)。此时可以写工厂函数包装器把这些函数指针作为参数传给测试。失败定位typed test 失败时输出里包含类型名能快速定位是哪个实现出了问题value-parameterized test 没有这个能力只能看迭代编号来推断不够直接。编译错误可读性写 typed test 时如果出错由于代码被模板化编译器错误往往更难消化。接口意识使用 typed tests 时要确保测试针对的是接口类型而非具体类型即要保证implicit_castMyInterface*(my_concrete_impl)成立而不仅仅是my_concrete_impl能用value-parameterized tests 在这一区域更不容易犯错。FAQ 最后给出的建议很实在两种方式都亲手试一遍实践是理解二者微妙差异的最好方式有了具体经验后自然知道下次该选哪个。五、死亡测试Death Tests深入死亡测试EXPECT_DEATH/ASSERT_DEATH等用于验证程序在预期位置崩溃的行为是 FAQ 中篇幅最重、也最容易出问题的领域。5.1 死亡测试为什么会变慢从fast到threadsafe2008 年 8 月googletest 把默认死亡测试风格从fast切换为threadsafe因为前者在线程化日志成为默认后已不再安全代价是大量死亡测试明显变慢——但这个改变是必要的。两种风格的具体差异可以在随仓库托管的进阶文档 advanced.md 的 How It Works 与 Death Test Styles 小节 中看到ASSERT_EXIT()会在子进程中执行死亡测试语句具体机制取决于平台与--gtest_death_test_style标志在 POSIX 上使用fork()Linux 上使用clone()派生子进程若风格为fast则直接执行死亡测试语句若为threadsafe子进程会重新执行整个测试二进制但加上额外参数使其只运行当前这一个死亡测试在 Windows 上使用CreateProcess()API同样是重新执行二进制来只运行目标死亡测试行为类似threadsafe模式。无论哪种风格父进程都会等待子进程结束然后检查两点① 子进程退出状态满足谓词② 子进程的 stderr 匹配正则表达式。如果死亡测试语句执行完毕而没有死亡子进程也会终止断言失败。你可以通过::testing::FLAGS_gtest_death_test_style threadsafe在main()中全局设置或在单个测试内设置googletest 会在每个测试前后保存/恢复标志。当前默认值是fast但官方保留未来更改的权利测试不应依赖此默认值。相关修复指引请参阅 advanced.md。5.2 死亡测试中修改的状态为何丢失EXPECT_DEATH等死亡断言在子进程中执行目的是让预期的崩溃不至于杀死测试程序父进程。因此它们在各自子进程中产生的内存副作用只在子进程中可见父进程完全观察不到——可以粗略理解为它们运行在一个平行宇宙里。一个典型陷阱如果你在死亡测试语句里调用了 gMock 的 mock 方法见 googlemock 目录父进程会认为这些调用从未发生过。解决办法是把EXPECT_CALL语句移进EXPECT_DEATH宏内部。5.3 死亡测试挂起或段错误怎么办死亡测试运行在子进程中其工作机制非常微妙写死亡测试前务必先读 advanced.md 的 How It Works 一节。FAQ 给出了一整套排查思路消除父进程中的多余线程死亡测试尤其不喜欢父进程里有多线程。首选方案是把EXPECT_DEATH()之外的线程创建全部去掉例如用 mock 或 fake 对象替代真实对象这是优先用测试夹具与替身理念的又一体现。处理不可控的线程有时某些必须用的库在main()之前就创建了线程。此时要么把尽可能多的活动移进EXPECT_DEATH()极端情况下全部移进去要么让它保持最少也可以试试把死亡测试风格设为threadsafe——更安全但更慢。保证确定性如果采用线程安全死亡测试子进程会从头重新运行整个测试程序所以要确保程序可以和自己并排运行且行为确定。归根结底这取决于良好的并发编程确保程序中没有竞态条件和死锁。FAQ 直言没有银弹。5.4 为什么ASSERT_DEATH会抱怨已经 join 的线程在 Linux 老式 pthread 库下从单线程跨入多线程是不可逆的第一次创建线程时除该线程外还会额外创建一个管理器线程所以你会得到 3 个而非 2 个线程之后 join 你的线程使计数减 1但管理器线程永远不会消失于是仍有 2 个线程——无法安全运行死亡测试。新的 NPTL 线程库不会创建管理器线程没有此问题但如果无法控制测试运行的机器就不应依赖这一点。5.5 为什么要求整个测试用例命名为*DeathTestgoogletest不会交错执行不同测试用例的测试它总是先跑完一个用例的所有测试再跑下一个。原因是它需要在用例的第一个测试运行前完成 setup、在用例结束后执行 teardown拆开运行会导致多次 setup/teardown效率低且语义不干净。如果按测试名而非用例名决定执行顺序就会遇到矛盾TEST_F(FooTest, AbcDeathTest) { ... } TEST_F(FooTest, Uvw) { ... } TEST_F(BarTest, DefDeathTest) { ... } TEST_F(BarTest, Xyz) { ... }FooTest.AbcDeathTest需要在BarTest.Xyz之前运行而用例之间不交错意味着必须整体先跑完FooTest再跑BarTest但死亡测试优先的要求又想让BarTest.DefDeathTest在FooTest.Uvw之前运行——两者冲突。以整个用例为单位命名*DeathTest如FooDeathTest后死亡测试会整体排在前面矛盾消解。5.6 不想整个用例叫*DeathTest怎么办完全可以把一个用例拆成FooTest和FooDeathTest两个用using别名让死亡测试用例直接复用原夹具名字本身也表明二者相关class FooTest : public ::testing::Test { ... }; TEST_F(FooTest, Abc) { ... } TEST_F(FooTest, Def) { ... } using FooDeathTest FooTest; TEST_F(FooDeathTest, Uvw) { ... EXPECT_DEATH(...) ... } TEST_F(FooDeathTest, Xyz) { ... ASSERT_DEATH(...) ... }5.7ASSERT_DEATH()的statement参数可以是什么ASSERT_DEATH(statement, regex)及任何死亡断言宏可以在任何statement合法的地方使用因此statement可以是当前上下文中任何有意义的 C 语句可以引用全局/局部变量可以是简单函数调用、复杂表达式或复合语句。FAQ 给出了完整示例// 死亡测试可以是一次简单的函数调用。 TEST(MyDeathTest, FunctionCall) { ASSERT_DEATH(Xyz(5), Xyz failed); } // 也可以是引用变量和函数的复杂表达式。 TEST(MyDeathTest, ComplexExpression) { const bool c Condition(); ASSERT_DEATH((c ? Func1(0) : object2.Method(test)), (Func1|Method) failed); } // 死亡断言可以在函数任何位置包括循环内。 TEST(MyDeathTest, InsideLoop) { // 验证 Foo(0) 到 Foo(4) 全部崩溃。 for (int i 0; i 5; i) { EXPECT_DEATH_M(Foo(i), Foo has \\d errors, ::testing::Message() where i is i); } } // 死亡断言也可以包含复合语句。 TEST(MyDeathTest, CompoundStatement) { // 验证 Bar(0) 到 Bar(4) 中至少有一个崩溃。 ASSERT_DEATH({ for (int i 0; i 5; i) { Bar(i); } }, Bar has \\d errors); }更多示例见 googletest 自带的 googletest-death-test-test.cc。5.8 死亡测试成功时为什么看不到子进程的 LOGEXPECT_DEATH()内语句产生的 LOG 消息只有在死亡测试失败时才会打印。因为无条件打印会干扰在父进程日志中搜索真正的问题。如果确实需要看到这些 LOG一个临时 hack 是故意破坏死亡测试例如临时改掉期望匹配的正则。FAQ 表示会在实现 fork-and-exec 风格死亡测试后考虑更永久的方案。六、测试夹具Test Fixture的设计与复用6.1 可以从另一个夹具派生夹具吗可以。每个测试夹具都有一个同名且对应的测试用例一个用例只能用同一个夹具但多个用例可能希望使用相同或略有不同的夹具例如希望 GUI 库的所有测试用例都不泄漏字体、画刷等重要系统资源。googletest 的共享方式把公共逻辑放进基类夹具再为每个用例从基类派生出各自的夹具用TEST_F()配合派生夹具写测试// 定义基类测试夹具。 class BaseTest : public ::testing::Test { protected: ... }; // 从 BaseTest 派生夹具 FooTest。 class FooTest : public BaseTest { protected: void SetUp() override { BaseTest::SetUp(); // 先初始化基类夹具。 ... additional set-up work ... } void TearDown() override { ... clean-up work for FooTest ... BaseTest::TearDown(); // 清理完 FooTest 后再销毁基类夹具 } ... functions and variables for FooTest ... }; // 使用夹具 FooTest 的测试。 TEST_F(FooTest, Bar) { ... } TEST_F(FooTest, Baz) { ... }注意两个关键点派生类SetUp()中要先调用BaseTest::SetUp()TearDown()中要最后调用BaseTest::TearDown()。必要时还可以从派生夹具继续派生googletest 对继承深度没有限制。完整示例见仓库内的 sample5_unittest.cc。6.2 应该用构造函数/析构函数还是SetUp()/TearDown()首先要记住googletest 不会在多个测试之间复用同一个夹具对象。每个TEST_F都会创建全新的夹具对象然后立即调用SetUp()、运行测试体、调用TearDown()最后删除该对象。在构造函数/析构函数与SetUp()/TearDown()之间前者通常更被推荐理由有三在构造函数中初始化成员变量时有机会将其声明为const防止意外修改让测试更明显地正确子类化夹具时子类构造函数保证先调用基类构造函数子类析构函数保证后调用基类析构函数而用SetUp()/TearDown()时子类可能忘记调用基类的SetUp()/TearDown()或在错误的时间调用。但在以下少数情况下仍然应该用SetUp()/TearDown()构造函数/析构函数体内无法使用ASSERT_xx宏见下文。如果 setup 操作可能产生致命失败并应阻止测试运行就必须用CHECK宏或改用SetUp()tear-down 操作可能抛异常时必须用TearDown()在析构函数中抛异常属于未定义行为通常会立即杀死程序。注意很多标准库如 STL在开启异常时可能抛异常因此想要写出无论是否启用异常都可移植的测试应优先TearDown()googletest 团队正考虑在启用异常的平台Windows、Mac OS、Linux 客户端上让断言宏抛异常以消除子例程向调用者传播失败的需求因此如果代码可能运行在这样平台上不应在析构函数中使用断言在构造函数/析构函数中不能对当前对象做虚函数调用调用声明为 virtual 的方法也会被静态绑定。因此如果需要调用一个会在派生类中被覆写的方法就必须使用SetUp()/TearDown()。6.3 多个用例共享夹具逻辑用typedef复用不想为每个用例都定义一个派生夹具类可以直接typedef复用typedef BaseTest FooTest; TEST_F(FooTest, Abc) { ... } TEST_F(FooTest, Def) { ... } typedef BaseTest BarTest; TEST_F(BarTest, Abc) { ... } TEST_F(BarTest, Def) { ... }这比逐一写class FooTest : public BaseTest {};简洁得多。6.4 为什么优先用夹具而不是全局变量测试往往需要改变全局变量的状态这会让副作用从一个测试逃逸到另一个测试、相互污染调试困难而夹具给每个测试提供一套全新但同名的变量测试之间保持独立全局变量污染全局命名空间夹具可以通过子类化复用全局变量很难做到——当多个用例有共性时这点尤其有用。6.5no matching function for call to FooTest::FooTest()的真相googletest 需要能够创建你的夹具类对象因此夹具必须拥有默认构造函数。通常编译器会自动生成但有两种情况必须自己定义如果显式声明了非默认构造函数DISALLOW_EVIL_CONSTRUCTORS()宏就会这么做就必须补一个默认构造函数哪怕是空的如果FooTest含const 非静态成员变量就必须定义默认构造函数并在构造函数的初始化列表中初始化该 const 成员早期gcc不强制初始化 const 成员这是已在gcc 4修复的 bug。6.6 不同命名空间中的同名TEST规则只有一条同一测试用例内的所有测试方法必须使用同一个夹具类。因此下面这段是合法的因为两个测试用的是同一个夹具类::testing::Testnamespace foo { TEST(CoolTest, DoSomething) { SUCCEED(); } } // namespace foo namespace bar { TEST(CoolTest, DoSomething) { SUCCEED(); } } // namespace bar而下面这段不合法会在运行时被 googletest 报错因为同名用例用了不同的夹具类namespace foo { class CoolTest : public ::testing::Test {}; // 夹具 foo::CoolTest TEST_F(CoolTest, DoSomething) { SUCCEED(); } } // namespace foo namespace bar { class CoolTest : public ::testing::Test {}; // 夹具 bar::CoolTest TEST_F(CoolTest, DoSomething) { SUCCEED(); } } // namespace bar七、断言宏的编译期陷阱7.1ASSERT_PRED*报 no matching function to call如果ASSERT_PRED*/EXPECT_PRED*使用的谓词函数是重载函数或模板函数编译器无法确定该选哪个版本。ASSERT_PRED_FORMAT*/EXPECT_PRED_FORMAT*则没有这个问题。遇到此错误时首选迁移到(ASSERT|EXPECT)_PRED_FORMAT*还能得到更好的失败消息如果不行就显式告诉编译器选哪个版本。例如有重载bool IsPositive(int n) { return n 0; } bool IsPositive(double x) { return x 0; }直接写EXPECT_PRED1(IsPositive, 5);会编译失败但这样写可以EXPECT_PRED1(static_castbool (*)(int)(IsPositive), 5);static_cast尖括号里是IsPositive()的int版本函数指针类型。模板函数可以用显式模板实参template typename T bool IsNegative(T x) { return x 0; }ASSERT_PRED1(IsNegativeint, -5);模板有多个参数时更有意思——下面这段不能编译ASSERT_PRED2(GreaterThanint, int, 5, 0);因为 C 预处理器认为你给ASSERT_PRED2传了 4 个参数。解决办法是把谓词函数用括号包起来ASSERT_PRED2((GreaterThanint, int), 5, 0);7.2 忽略RUN_ALL_TESTS()的返回值很危险一些人写RUN_ALL_TESTS();而不是return RUN_ALL_TESTS();这是错误且危险的测试服务需要看到RUN_ALL_TESTS()的返回值来判断测试是否通过。如果main()忽略它即使存在断言失败测试也会被认为成功。googletest 已在gcc下强制修复——忽略返回值会直接编译报错因为该代码原本就是坏的所以不存在破坏既有测试的问题。看到这个编译器报错时修复方式很简单确保该值被用作main()的返回值。7.3 void value not ignored as it ought to be这个错误几乎可以断定是你在非 void 函数里用了ASSERT_*()。由于 googletest 的构建系统禁用了异常ASSERT_*()只能在返回void的函数中使用。更多细节见 advanced.md 的 Assertion Placement 一节。7.4 构造函数或析构函数不能返回值的报错为了支持向断言流式输出消息的语法ASSERT_EQ(1, Foo()) blah blah foo;googletest 不得不放弃在构造函数和析构函数中使用ASSERT*和FAIL*EXPECT*和ADD_FAILURE*不受影响。变通办法把构造函数/析构函数的内容挪到一个私有的 void 成员函数中或者改用EXPECT_*()。相关说明见 advanced.md。7.5 静态 const 成员变量的 undefined reference如果类里有静态数据成员// foo.h class Foo { ... static const int kBar 100; };还必须在foo.cc中在类体外定义它const int Foo::kBar; // 这里不要初始化器。否则你的代码是非法的 C可能在意想不到的地方出错——尤其是把它用在 googletest 比较断言EXPECT_EQ等中时会得到 undefined reference 链接错误。以前能编译通过不代表代码合法只是你运气好而已。7.6SetUp()为什么没被调用C 是大小写敏感的。你是不是把它拼成了Setup()同样有人把SetUpTestSuite()拼成SetupTestSuite()然后纳闷它为什么从没被调用过。八、测试工程的实用技巧与工作流8.1 临时禁用某个测试DISABLED_前缀有暂时修不好的坏测试时给测试名加DISABLED_前缀即可把它排除在运行之外。这比注释掉代码或用#if 0好因为禁用测试仍然会被编译不会腐烂。需要把禁用测试也纳入执行时用--gtest_also_run_disabled_tests标志运行测试程序。8.2 googletest 输出被 LOG 消息淹没googletest 的输出本应是简洁、人性化的报告如果测试自身输出文本就会与 googletest 输出混在一起难以阅读。解决办法很简单LOG消息走stderr而 googletest 输出走stdout用重定向即可分离$ ./my_test gtest_output.txt对应到 Weex Coretest.sh 中的make test会借助 CTestadd_test(WeexTests HelloTest)统一收集并展示测试结果。8.3 代码如何检测是否运行在测试中FAQ 强烈反对在代码里嗅探自己是否运行在测试环境中并据此改变行为——这会把仅测试用的逻辑泄漏进生产代码且无法保证这些测试专用路径不会被生产环境误执行还容易引发 Heisenbug观察改变结果。googletest 刻意不提供这种能力。推荐的替代方案是依赖注入Dependency Injection从测试代码与生产代码分别注入不同功能生产代码完全不链接测试逻辑BUILD目标的testonly属性有助于保证这一点就不会有误执行的风险。如果你真的、真的、真的别无选择且遵守测试程序名以_test结尾的约定可以用在main()中嗅探可执行文件名argv[0]这种可怕的 hack——但请把它当成最后手段。8.4 在 Emacs 中直接跳转到失败行googletest 的失败消息格式被 Emacs 以及 acme、Xcode 等众多 IDE 识别。在 Emacs 中如果 googletest 消息出现在 compilation buffer 里它就是可点击的可以直接跳转到失败位置。8.5ProtocolMessageEquals的 proto 描述符运行时错误注意ProtocolMessageEquals与ProtocolMessageEquiv现已弃用请改用EqualsProto等。这两个匹配器近期被重新定义对无效的 protocol buffer 定义更不宽容。如果你有foo.proto没有完整限定其引用的消息类型例如写messageBar而本应是messageblah.Bar现在会出现类似下面的运行时错误... descriptor.cc:...] Invalid proto descriptor for file path/to/foo.proto: ... descriptor.cc:...] blah.MyMessage.my_field: .Bar is not defined.看到这种错误说明你的.proto文件本身坏了需要把类型写成完全限定名——新的ProtocolMessageEquals/ProtocolMessageEquiv定义只是恰好暴露了你的 bug。8.6 在 Windows 上抑制内存泄漏消息由于静态初始化的 googletest 单例需要堆分配Visual C 的内存泄漏检测器会在程序运行结束时报告内存泄漏。最简单的规避方式是用_CrtMemCheckpoint与_CrtMemDumpAllObjectsSince调用不报告静态初始化的堆对象详见 MSDN 的堆检查/调试例程。九、总结googletest FAQ 表面上是一堆零散问答实则串起了 C 单元测试的几条主线命名即契约下划线规则、*DeathTest命名、宏的展开本质TEST生成类名、断言宏对sizeof/模板/流式输出的依赖、进程模型死亡测试的子进程语义与线程禁忌、夹具生命周期新鲜对象、构造函数 vsSetUp、继承与typedef复用以及一批能让你少走弯路的工程细节DISABLED_前缀、stdout/stderr 分离、返回值不可忽略。这些知识点在 Weex Core 中同样适用——仓库的 test/CMakeLists.txt、HelloTest.cpp 与 scripts/test.sh 已经搭建好了一条配置 → 编译 → 运行的完整测试链路遵循本文梳理的规范去写测试就能避免绝大多数 googletest 的经典陷阱。赞分享移动开发跨平台前端UI组件OpenHarmony【免费下载链接】weexA framework for building Mobile cross-platform UI项目地址https://gitcode.com/gh_mirrors/we/weex点击查看免费下载相关推荐Weex Core 中的 Google Testgoogletest 1.9C 单元测试框架集成指南Weex Core 中的 Google Testgoogletest 1.9C 单元测试框架集成指南 Google Test 是 Google 出品的移动开发跨平台前端UI组件OpenHarmonygMock FAQ 全解GoogleTest Mock 框架的常见疑难与源码级解析gMock FAQ 全解GoogleTest Mock 框架的常见疑难与源码级解析 导读 本文围绕 GoogleTest 仓库中 docs/gmock_faq测试使用 CMake 快速集成 GoogleTest 构建 C 单元测试从 FetchContent 到源码级实战使用 CMake 快速集成 GoogleTest 构建 C 单元测试从 FetchContent 到源码级实战 导读 GoogleTestgtest/g序列化后端上一篇Scoop故障排除指南解决99%常见问题的实用方案下一篇从崩溃到丝滑Apache Flink状态后端终极选型指南RocksDB/Heap/Changelog全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考