miniblink49 V8 6.7 自带 Google Test：在 Xcode 中构建 gtest.framework 单元测试的完整指南

miniblink49 V8 6.7 自带 Google Test在 Xcode 中构建 gtest.framework 单元测试的完整指南【免费下载链接】miniblink49a lighter, faster browser kernel of blink to integrate HTML UI in your app. 一个小巧、轻量的浏览器内核用来取代wke和libcef项目地址: https://gitcode.com/GitHub_Trending/mi/miniblink49本文基于 miniblink49 仓库中 V8 6.7 组件自带的 Google Test V1.7 Xcode 指南完整讲解如何在 Mac OS X 的 Xcode 工程中集成 Google Testing Frameworkgtest.framework、创建单元测试 target、配置DYLD_FRAMEWORK_PATH运行环境并通过源码级的xcconfig配置与示例工程印证每一步的实际效果。读完后你可以在这套随仓库分发的 gtest 源码位于 v8_6_7/testing/gtest之上独立搭建一套可在 Xcode 中编译、链接并运行的 C/C 单元测试体系。一、背景这套 Google Test 在仓库中的位置miniblink49 是一个轻量的 Blink 内核用于在应用中内嵌 HTML UI。仓库内嵌了多份 V8 版本源码v8_4_5到v8_7_5其中 V8 6.7 的完整测试树位于 v8_6_7/testingGoogle Test 框架则完整包含在 v8_6_7/testing/gtest 中框架本体源码在 v8_6_7/testing/gtest/src 与 v8_6_7/testing/gtest/include各版本文档V1.5 / V1.6 / V1.7与主文档集中在 v8_6_7/testing/gtest/docs本篇依据的是V1_7_XcodeGuide.mdMac 侧的 Xcode 工程在 v8_6_7/testing/gtest/xcode包含gtest.xcodeproj、Config/一组.xcconfig配置文件、Samples/FrameworkSample 示例工程与Scripts/。指南开篇的适用前提需要说明文中讨论的gtest.framework并不存在于 Google Test 的 tag 版本发布中只在 trunk主干中提供。因此在 macOS 上做单元测试集成时需要按指南从源码构建 framework而不是直接下载预编译产物。二、快速开始七步建立 gtest 测试目标指南给出的快速开始Quick Start步骤如下可先照做一遍后文再逐步展开使用如下命令从 Google Test 官方仓库检出源码svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-onlyminiblink49 仓库中已内置一份同样的 gtest 源码见 v8_6_7/testing/gtest可直接以该目录为${GTEST_DIR}。打开googletest-read-only/xcode/目录下的gtest.xcodeproj构建出gtest.framework对应仓库内 v8_6_7/testing/gtest/xcode/gtest.xcodeproj。在自己的 Xcode 工程中创建一个 Shell Tool 类型的 target命名为UnitTests之类。将gtest.framework添加到工程中并加入UnitTests的 Link Binary with Libraries 构建阶段。将单元测试源码加入UnitTests的 Compile Sources 构建阶段。编辑UnitTests可执行文件在运行环境变量中新增DYLD_FRAMEWORK_PATH其值为 gtest.framework 所在目录相对于可执行文件的路径。Build and Go。下面逐节深入说明每一步的原理与细节。三、获取源码SVN trunk 与 svn:externals 两种方式3.1 直接匿名检出由于gtest.framework只存在于 trunk 中最基本的获取方式是匿名 SVN 检出svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only3.2 用 svn:externals 管理为外部依赖如果你的代码库本身使用 Subversion更推荐把 Google Test 声明为外部依赖external dependency。这样任何人检出你的仓库时都会自动获得指定版本的 Google Test无需单独操作既简化了项目搭建也减少了仓库中的拷贝代码。操作要点决定外部源码的存放位置。可以放在trunk内部希望它作为发布分支的一部分另一种选择是放在 trunk 之外、一个带版本号的目录中例如third-party/googletest/1.0.1。设置 svn:externals 属性。位置确定后用svn propedit svn:externals _目录_为仓库中某个目录设置属性——该目录本身不包含代码只是外部依赖的版本化父目录。svn propedit会唤起 Subversion 编辑器便于编辑这种可能多行的长属性。两个可选技巧检出 tag 分支使用对应的 tag URL 即可例如http://googletest.googlecode.com/svn/tags/release-1.0.1锁定 trunk 到某个修订号svn:externals 支持-r_##_选项例如externals/src/googletest -r60 http://googletest.googlecode.com/svn/trunk。指南给出的一个svn:externals实际配置示例通过svn propget读取 trunk 上的属性值该配置会把 Google Test 检出到trunk/externals/src/googletest/目录[Computer:svn] user$ svn propget svn:externals trunk externals/src/googletest http://googletest.googlecode.com/svn/trunk四、把 Framework 加入你的项目两种集成方式指南区分了两种常见做法分别对应稳定使用与跟随 trunk两种开发模式。4.1 方式一直接使用已构建的 framework最简单打开xcode/目录中的gtest.xcodeproj手动构建 framework然后通过上下文菜单的 Add - Existing Framework... 或主菜单的 Project - Add... 把构建好的 framework 加入自己的工程。gtest.framework是可重定位的relocatable内部包含了编写测试所需的全部头文件和目标代码。需要注意的代价是每次升级项目中的 Google Test 版本都必须重新构建一次 framework。4.2 方式二管理 gtest.xcodeproj 本身Living off the trunk如果你要持续使用 Google Test trunk 的最新特性或者你本身就是 Google Test 的开发者你希望每次源码更新后 framework 都随之重建。这时应把gtest.xcodeproj文件而不是 framework 本身加入自己的 Xcode 工程。之后从工程的 disclosure triangle展开三角里可以看到构建产物其中就有gtest.framework可以把它加入到你的测试 target下一节详述。4.3 仓库源码印证Xcode 工程的关键配置miniblink49 中随附的 gtest Xcode 工程结构正好与上述流程对应xcode/目录下的配置文件说明了这个 framework 是如何被构建出来的v8_6_7/testing/gtest/xcode/Config/General.xcconfig 定义了通用构建策略ARCHS i386 x86_64 ppc ppc64——同时构建 32/64 位 Intel 与 PPC 架构的通用二进制universal binary这也是为什么构建产物可以作为可重定位 framework 直接分发给他人SDKROOT $(DEVELOPER_SDK_DIR)/MacOSX10.4u.sdk与MACOSX_DEPLOYMENT_TARGET 10.4——默认以 10.4 SDK 为最小部署目标PREBINDING NO、ZERO_LINK NO、SEPARATE_STRIP YES——关闭 10.3 之后已无益的 prebinding使用外部 strip 以规避当时的 Xcode 链接问题最严格警告策略WARNING_CFLAGS -Wall -Werror -Wendif-labels -Wnewline-eof -Wno-sign-compare -Wshadow。v8_6_7/testing/gtest/xcode/Config/FrameworkTarget.xcconfig 定义了 framework target 专属设置GCC_DYNAMIC_NO_PIC NO——动态库必须采用位置无关代码PICSTRIP_STYLE non-global——动态库不得剥离外部符号否则链接方取不到符号SKIP_INSTALL NO——允许用户通过xcodebuild指定$DSTROOT来安装。另有 v8_6_7/testing/gtest/xcode/Config/TestTarget.xcconfig 用于示例中的测试 targetDebugProject.xcconfig/ReleaseProject.xcconfig分别对应两种构建配置。这些配置解释了指南中framework 是可重定位的、包含头和目标代码这一说法的工程来源。另外v8_6_7/testing/gtest/README.md 还给出了与 Xcode 相关的两条补充事实在命令行上进入 xcode 目录后直接执行xcodebuild即可在默认构建位置构建 Release 配置的gtest.framework若使用 Xcode 4.x 及更高版本打开这个旧工程需要二选一修改xcode/Config/General.xcconfig注释掉SDKROOT、MACOS_DEPLOYMENT_TARGET、GCC_VERSION三项代价是失去针对更旧 Mac OS X 版本的能力或安装一个更早版本的 SDK。五、创建测试 target 并链接 framework5.1 建立 Shell Tool target新建一个 Shell Tool 类型的 target该模板在 BSD、Cocoa、Carbon 分类下都可选把你的单元测试源码加入该 target 的 Compile Sources 构建阶段。之所以用 Shell Tool而不是 Cocoa Application是因为单元测试的可执行文件不需要 bundle 结构本质上就是一个命令行程序。5.2 按集成方式添加 gtest.framework方式一直接使用 framework把gtest.framework加入测试 target 的 Link Binary with Libraries 构建阶段。编译期 Xcode 需要知道你在链接 gtest.framework——这一步会让 Google Test 的头文件进入头文件搜索路径同时告诉链接器去哪里找这个库。方式二管理 xcodeproj除了同样把gtest.framework加入 Link Binary with Libraries 之外还要把gtest.framework作为依赖dependency加到单元测试 target 上这样每次构建你的 target 时 Xcode 都会确保 framework 是最新的。最后如果你的工程与 Google Test 不共享构建目录还需要通过一个 Run Script 构建阶段把gtest.framework复制到你自己的构建产物目录中。六、配置运行环境DYLD_FRAMEWORK_PATH 与 dyld 报错处理6.1 为什么必须设置 DYLD_FRAMEWORK_PATH单元测试可执行文件是一个 shell tool没有 bundle因此没有Contents/Frameworks目录来安放 gtest.framework。于是必须在运行时告诉动态链接器dyld到别处去搜索这个 framework。做法是在 Edit Active Executable ... 的 Arguments 标签页中Variables to be set in the environment: 区域设置环境变量DYLD_FRAMEWORK_PATH。其取值是 gtest.framework 所在目录的路径相对路径或绝对路径均可。6.2 配置错误时的典型报错如果DYLD_FRAMEWORK_PATH没有设置正确你会看到类似这样的 dyld 报错[Session started at 2008-08-15 06:23:57 -0600.] dyld: Library not loaded: loader_path/../Frameworks/gtest.framework/Versions/A/gtest Referenced from: /Users/username/Documents/Sandbox/gtestSample/build/Debug/WidgetFrameworkTest Reason: image not found6.3 排查方法修复步骤先进入报错信息中 Referenced from: 一栏所指的可执行文件所在目录然后在终端当前已位于该目录中找到 gtest.framework 所在目录相对于这里的相对路径——这个路径就是DYLD_FRAMEWORK_PATH应当设置的值。从报错信息本身可以看出 framework 是被以loader_path/../Frameworks/gtest.framework的方式引用的因此路径必须能让 dyld 在可执行文件旁边解析到真实的 framework 位置这与第四节提到的不共享构建目录时需要用 Run Script 复制 framework是同一个问题的两面。七、Build and Go验证测试输出配置完成后点击 Build and Go测试即被执行控制台输出大致如下[Session started at 2008-08-06 06:36:13 -0600.] [] Running 2 tests from 1 test case. [----------] Global test environment set-up. [----------] 2 tests from WidgetInitializerTest [ RUN ] WidgetInitializerTest.TestConstructor [ OK ] WidgetInitializerTest.TestConstructor [ RUN ] WidgetInitializerTest.TestConversion [ OK ] WidgetInitializerTest.TestConversion [----------] Global test environment tear-down [] 2 tests from 1 test case ran. [ PASSED ] 2 tests. The Debugger has exited with status 0.7.1 这份输出的真实来源仓库中的 FrameworkSample 示例这段输出并非虚构示例——它与仓库中 gtest Xcode 示例工程的测试代码逐条对应。示例工程位于 v8_6_7/testing/gtest/xcode/Samples/FrameworkSample其测试源码 widget_test.cc 恰好定义了指南输出中出现的WidgetInitializerTest测试类// 验证构造函数是否正确设置了 Widget 的内部状态 TEST(WidgetInitializerTest, TestConstructor) { Widget widget(1.0f, name); EXPECT_FLOAT_EQ(1.0f, widget.GetFloatValue()); EXPECT_EQ(std::string(name), widget.GetStringValue()); } // 验证 float/string 到 int/char* 的转换 TEST(WidgetInitializerTest, TestConversion) { Widget widget(1.0f, name); EXPECT_EQ(1, widget.GetIntValue()); size_t max_size 128; char buffer[max_size]; widget.GetCharPtrValue(buffer, max_size); EXPECT_STREQ(name, buffer); }对应指南中的[ RUN ]/[ OK ]两对TestConstructor与TestConversion以及2 tests from 1 test case的统计行。几个值得注意的实现细节测试文件通过#include Widget/widget.h以 framework 风格引用被测代码widget.h / widget.cc 组成示例的 Widget 类头文件经由 framework 的搜索路径被解析该 target没有自带main函数。widget_test.cc末尾的注释明确说明它复用链接进 framework 的那个 Google Test 版 main其行为等价于int main(int argc, char** argv) { testing::InitGoogleTest(argc, argv); return RUN_ALL_TESTS(); }这正是把 framework 加入 Link Binary 即可获得完整测试入口这一集成方式的关键测试 main 由gtest.framework提供。示例还附带 runtests.sh 脚本与 WidgetFramework.xcodeproj 工程可作为Shell Tool target 外部 framework这一完整模式的参照工程。八、小结与延伸单元测试是确保数据模型在快速开发与重构期间始终保持有效的可靠手段。Google Testing Framework 是一个优秀的 C/C 单元测试框架并且能与 Xcode 开发环境良好集成。结合本仓库的实际内容可以把全文的操作链条归纳为从 trunk 获取或复用仓库内 v8_6_7/testing/gtest 之外的 v8_6_7/testing/gtest源码用gtest.xcodeproj构建gtest.framework创建 Shell Tool target测试源码进 Compile Sourcesframework 进 Link Binary with Libraries跟随 trunk 时再加 target 依赖与 Run Script 复制逻辑在 Arguments 的环境变量中设置DYLD_FRAMEWORK_PATH指向 framework 所在目录用 dyld 报错中的 Referenced from: 相对路径法定位取值Build and Go对照 FrameworkSample 的输出格式验证[ PASSED ]与退出状态 0。此外v8_6_7/testing/gtest/README.md 中还记录了大量与本指南配合使用的控制宏如-DGTEST_USE_OWN_TR1_TUPLE、-DGTEST_HAS_PTHREAD、-DGTEST_CREATE_SHARED_LIBRARY等与 CMake 构建方式当你的构建体系不是纯 Xcode 时可作为同一份 gtest 源码的替代集成入口继续查阅。【免费下载链接】miniblink49a lighter, faster browser kernel of blink to integrate HTML UI in your app. 一个小巧、轻量的浏览器内核用来取代wke和libcef项目地址: https://gitcode.com/GitHub_Trending/mi/miniblink49创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考