第一章 UT单元测试——GoogleTest通用构建说明

系列文章目录

第一章 UT单元测试——GoogleTest通用构建说明
第二章 UT单元测试——GTest框架实例



前言

第一章就介绍GTest通用构建说明吧。


GoogleTest通用构建说明

设置

要构建GoogleTest及其使用它的测试,您需要告诉您的构建
系统在哪里可以找到其标头和源文件。确切的方法
取决于您使用的构建系统,通常很简单。

用CMake构建

GoogleTest随附CMake构建脚本
([CMakeLists.txt](https://github.com/google/googletest/blob/master/CMakeLists.txt))
可以在各种平台上使用(“ C”代表跨平台。)。
如果尚未安装CMake,则可以从以下位置免费下载
http://www.cmake.org/

CMake通过生成本机Makefile或构建可在以下版本中使用的项目来工作
您选择的编译器环境。您可以将GoogleTest构建为
独立项目,也可以将其合并到现有的CMake构建中,以用于
另一个项目。

独立CMake项目

将GoogleTest构建为独立项目时,典型的工作流程开始

git clone https://github.com/google/googletest.git -b版本-1.10.0
cd googletest#克隆的存储库的主目录。
mkdir build#创建一个目录来保存构建输出。
光盘制作
cmake ..#为GoogleTest生成本机构建脚本。

上面的命令默认还包含GoogleMock。所以,如果你想
仅构建GoogleTest,您应该将最后一个命令替换为

cmake .. -DBUILD_GMOCK = OFF

如果您使用的是\ * nix系统,则现在应该在当前目录中看到一个Makefile。
目录。只需输入“ make”即可构建GoogleTest。然后您可以简单地安装
如果您是系统管理员,请使用GoogleTest。

制作
sudo make install#默认安装在/ usr / local /

如果您使用Windows并安装了Visual Studio,则应输入一个“ gtest.sln”文件和
将创建几个.vcproj文件。然后,您可以使用Visual构建它们
工作室。

扫描二维码关注公众号,回复: 12881382 查看本文章

在安装了Xcode的Mac OS X上,将生成.xcodeproj文件。

整合到现有的CMake项目中

如果要在已经使用CMake的项目中使用GoogleTest,最简单
方式是获取已安装的库和头文件。

*使用find_package(或pkg_check_modules)导入GoogleTest。为了
例如,如果find_package(GTest CONFIG REQUIRED)成功,则可以使用
库分别为“ GTest :: gtest”,“ GTest :: gmock”。

一种更强大,更灵活的方法是将GoogleTest作为其中的一部分
直接进行项目。这是通过使GoogleTest源代码可用于
主版本,并使用CMake的add_subdirectory()命令将其添加。这
具有显着的优势,即可以使用相同的编译器和链接器设置
在GoogleTest和项目的其余部分之间使用,因此与
避免使用不兼容的库(例如调试/发行版)等。这是
在Windows上特别有用。使GoogleTest的源代码可用于
可以通过几种不同的方式完成主要构建:

  • 手动下载GoogleTest源代码并将其放置在已知的位置
    地点。这是最不灵活的方法,可能会使其更加困难
    与连续集成系统等配合使用
  • 将GoogleTest源代码作为直接副本嵌入主项目的
    源树。这通常是最简单的方法,但也是最困难的方法
    不断更新。一些组织可能不允许这种方法。
  • 将GoogleTest添加为git子模块或同等子模块。这可能并不总是
    可能或适当的。例如,Git子模块具有自己的一组
    优点和缺点。
  • 作为构建的配置步骤的一部分,使用CMake下载GoogleTest。这
    只是稍微复杂一点,但没有其他的限制
    方法。

上面的最后一种方法是使用一小段CMake代码实现的
单独的文件(例如,CMakeLists.txt.in)复制到构建区域,然后
然后在CMake阶段作为子版本调用。该目录是
使用add_subdirectory()进入主版本。例如:

新文件CMakeLists.txt.in

cmake
cmake_minimum_required(版本2.8.12)

专案(googletest-download NONE)

包括(ExternalProject)
ExternalProject_Add(googletest
GIT_REPOSITORY https://github.com/google/googletest.git
GIT_TAG主
SOURCE_DIR“ $ {CMAKE_CURRENT_BINARY_DIR} / googletest-src”
BINARY_DIR“ $ {CMAKE_CURRENT_BINARY_DIR} / googletest-build”
CONFIGURE_COMMAND“”
BUILD_COMMAND“”
INSTALL_COMMAND“”
TEST_COMMAND“”


现有版本的`CMakeLists.txt`:

cmake
#在配置时间下载并解压缩googletest
configure_file(googletest-download / CMakeLists.txt中的CMakeLists.txt。)
execute_process(COMMAND $ {CMAKE_COMMAND} -G“ $ {CMAKE_GENERATOR}”。
  RESULT_VARIABLE结果
  WORKING_DIRECTORY $ {CMAKE_CURRENT_BINARY_DIR} / googletest-download)
如果(结果)
  信息(FATAL_ERROR“针对googletest的CMake步骤失败:$ {result}”)
万一()
execute_process(COMMAND $ {CMAKE_COMMAND} --build。
  RESULT_VARIABLE结果
  WORKING_DIRECTORY $ {CMAKE_CURRENT_BINARY_DIR} / googletest-download)
如果(结果)
  消息(FATAL_ERROR“针对googletest的构建步骤失败:$ {result}”)
万一()

#防止覆盖父项目的编译器/链接器
Windows上的#个设置
设置(gtest_force_shared_crt ON CACHE BOOL“” FORCE)

#将googletest直接添加到我们的版本中。这定义
#gtest和gtest_main目标。
add_subdirectory($ {CMAKE_CURRENT_BINARY_DIR} / googletest-src
                 $ {CMAKE_CURRENT_BINARY_DIR} / googletest-build
                 EXCLUDE_FROM_ALL)

#现在只需根据需要链接到gtest或gtest_main。例如
add_executable(示例example.cpp)
target_link_libraries(例如gtest_main)
add_test(NAME example_test COMMAND示例)

请注意,由于使用了以下方法,因此此方法需要CMake 2.8.2或更高版本
ExternalProject_Add()命令。对上述技术进行了更详细的讨论
在[此单独的文章](http://crascit.com/2015/07/25/cmake-gtest/)中
还包含该技术的全面概括实现的链接。

Visual Studio动态vs静态运行时

默认情况下,新的Visual Studio项目动态链接C运行时,但是
GoogleTest静态链接它们。这将产生一个看起来像错误
类似于以下内容:gtest.lib(gtest-all.obj):错误LNK2038:不匹配
检测到“ RuntimeLibrary”:值“ MTd_StaticDebug”与值不匹配
main.obj中的“ MDd_DynamicDebug”

GoogleTest已经为此提供了一个CMake选项:gtest_force_shared_crt

启用此选项将使gtest也动态链接运行时,并且
匹配包含它的项目。

C ++标准版本

需要一个支持C ++ 11的环境才能成功构建
GoogleTest。确保这一点的一种方法是在顶层指定标准
项目,例如通过使用set(CMAKE_CXX_STANDARD 11)命令。如果这
是不可行的,例如在使用GoogleTest进行验证的C项目中,
然后可以通过将其添加到cmake的选项中来指定它
DCMAKE_CXX_FLAGS选项。

调整GoogleTest

GoogleTest可以在多种环境中使用。默认配置可能
在某些环境中无法立即使用(或可能无法正常使用)。然而,
您可以通过在编译器上定义控制宏来轻松调整GoogleTest
命令行。通常,这些宏的命名类似于“ GTEST_XYZ”,您可以定义
它们设置为1或0即可启用或禁用某些功能。

我们在下面列出了最常用的宏。有关完整列表,请参见文件
[include / gtest / internal / gtest-port.h](https://github.com/google/googletest/blob/master/googletest/include/gtest/internal/gtest-port.h)。

多线程测试

如果有pthread库,则GoogleTest是线程安全的。后
#include“ gtest / gtest.h”,您可以检查
GTEST_IS_THREADSAFE宏以查看是否存在这种情况(如果宏为
将#defined设置为1,如果未定义则为no。)。

如果GoogleTest无法正确检测到pthread是否在您的计算机中可用
环境,您可以强制使用

-DGTEST_HAS_PTHREAD = 1

或者

-DGTEST_HAS_PTHREAD = 0

当GoogleTest使用pthread时,您可能需要向编译器添加标志和/或
链接器以选择pthread库,否则您将获得链接错误。如果您使用
CMake脚本,这已为您解决。如果您使用自己的构建脚本,
您需要阅读编译器和链接器的手册,以了解哪些标志
添加。

###作为共享库(DLL)

GoogleTest紧凑,因此大多数用户都可以将其构建并链接为静态库
为简单起见。您可以选择将GoogleTest用作共享库(已知
作为Windows上的DLL)。

要将* gtest *编译为共享库,请添加

-DGTEST_CREATE_SHARED_LIBRARY = 1

编译器标志。您还需要告诉链接器产生一个共享的
而是使用库-查阅链接器手册以了解操作方法。

要编译使用gtest共享库的* test *,请添加

-DGTEST_LINKED_AS_SHARED_LIBRARY = 1

编译器标志。

注意:虽然今天使用某些方法在技术上并不需要上述步骤
编译器(例如GCC),如果我们决定
提高加载库的速度(请参阅
有关详细信息,请参见http://gcc.gnu.org/wiki/Visibility。因此,建议您
在将GoogleTest用作共享库时始终添加上述标志。
否则,将来发布的GoogleTest可能会破坏您的构建脚本。

避免宏名称冲突

在C ++中,宏不遵循命名空间。因此,两个都定义了一个
如果您同时使用#include和这两个定义,则同名宏会发生冲突。万一
GoogleTest宏与另一个库发生冲突,您可以强制GoogleTest执行以下操作:
重命名其宏以避免冲突。

具体来说,如果GoogleTest和其他一些代码都定义了宏FOO,则可以
添加

-DGTEST_DONT_DEFINE_FOO = 1

到编译器标志,以告知GoogleTest将宏的名称从“ FOO”更改为
GTEST_FOO。当前,“ FOO”可以是“失败”,“成功”或“测试”。为了
例如,使用-DGTEST_DONT_DEFINE_TEST = 1,您需要编写

GTEST_TEST(SomeTest,DidThis){...}

代替

TEST(SomeTest,DoesThis){...}

为了定义一个测试。

猜你喜欢

转载自blog.csdn.net/zmkzmkok/article/details/114969963