gtest单元测试框架介绍及简单使用

简介: gtest单元测试框架介绍及简单使用

Gtest介绍


Gtest是Google的一个开源框架,它主要用于写单元测试,检查真自己的程序是否符合预期行为。可在多个平台上使用(包括Linux, Mac OS X, Windows, Cygwin和Symbian)。它提供了丰富的断言、致命和非致命失败判断,能进行值参数化测试、类型参数化测试、“死亡测试”。


下载安装


相关地址:


http://googletest.googlecode.com/files/gtest-1.3.0.zip


GitHub - google/googletest: GoogleTest - Google Testing and Mocking Framework


windows下推荐使用vcpkg工具下载安装,安装很简便。


默认下载安装的是32位的,若需要64位的则指定.\vcpkg.exe install gtest:x64-windows


.\vcpkg.exe install gtest


相关特性


一 .断言


一般的要测试一个方法(函数)是否是正常执行的,可以提供一些输入数据。在调用这个方法(函数)后得到输出数据,然后检查输出的数据是否与我们期望的结果是一致的。若一致则说明这个方法的逻辑是正确的,否则就有问题。  


在对输出结果进行检查(check)时,Gtest为我提供了一系列的断言(assertion)来进行代码测试,这些宏有点类似于函数调用。当断言失败时Gtest将会打印出assertion时的源文件和出错行的位置以及附加的失败信息。这些输出的附加信息用户可以直接通过“<<”在这些断言宏后面。


Gtest中,断言的宏可以理解为分为两类,一类是ASSERT系列,一类是EXPECT系列。


ASSERT_系列的断言(Fatal assertion):


当检查点失败时,退出当前函数(注意:并非退出当前案例)。


EXPECT_系列的断言(Nonfatal assertion):


当检查点失败时,继续执行下一个检查点(每一个断言表示一个测试点)。


通常情况应该首选使用EXPECT_,因为ASSERT_*在报告完错误后不会进行清理工作,有可能导致内存泄露问题。


断言中提供以下几种检查方法:


布尔类型检查



二值检查



字符串检查



异常检查



浮点检查



相近值检查



二 .宏测试


TEST宏


TEST宏的第一个参数是test_suite_name(测试套件名),第二个参数是test_name(测试特例名)。


测试套件(Test Case)是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求。


测试特例是测试套件下的一个(组)测试。


对于测试套件名和测试特例名,不能有下划线(_)。因为GTest源码中需要使用下划线把它们连接成一个独立的类名。不能有相同的“测试套件名和特例名”的组合——否则类名重合。


测试套件名和测试特例名的分开,使得我们编写的测试代码有着更加清晰的结构。


TEST_F宏


使用TEST_F前需要创建一个固件类,继承esting::Test类。


在类内部使用public或者protected描述其成员,为了保证实际执行的测试子类可以使用其成员变量。在构造函数或者继承于::testing::Test类中的SetUp方法中可以实现我们需要构造的数据。在析构函数或者继承于::testing::Test类中的TearDown方法中可以实现一些资源释放的代码。


第一个参数为测试套件名(必须与创建的固件类名一致),第二个为测试名,可任意取。


TEST_F宏和TEST宏的实现接近,只是TEST_F宏的封装更加开放一些,对TEST宏的功能多了一些扩展。


TEST_F与TEST的区别,TEST_F提供了一个初始化函数(SetUp)和一个清理函数(TearDown)。在TEST_F中使用的变量可以在初始化函数SetUp中初始化,在TearDown中销毁。所有的TEST_F是互相独立的,都是在初始化以后的状态开始运行。一个TEST_F不会影响另一个TEST_F所使用的数据,多个测试场景需要相同数据配置的情况用 TEST_F。


TEST_P宏


在设计测试案例时,经常需要考虑给被测函数传入不同的值的情况。我们之前的做法通常是写一个通用方法然后编写在测试案例调用它。即使使用了通用方法,这样的工作也是有很多重复性的。


用TEST这个宏,需要编写如下的测试案例,每输入一个值就需要写一个测试点,这还只是在一个测试中,如果把每个测试点单独创建一个测试,工作量就更大。使用TEST_P这个宏,对输入进行参数化,就简单很多。


预处理事件机制


gtest 提供了多种预处理事件机制,方便我们在测试之前或之后做一些操作。


1. 全局的,所有测试执行前后。


2. TestSuite级别的,在某测试套件中第一个测试前,最后一个测试执行后。


3. TestCase级别的,每个测试前后。


1.全局事件


要实现全局事件,必须写一个类继承testing::Environment类,实现里面的SetUp和TearDown方法。


1. SetUp()方法在所有案例执行前执行。


2. TearDown()方法在所有案例执行后执行。


还需要在main函数中通过调用testing::AddGlobalTestEnvironment这个函数将事件挂进来,也就是说,我们可以写很多个这样的类,然后将他们的事件都挂上去,

AddGlobalTestEnvironment这个函数要放在RUN_ALL_TEST之前。



2.TestSuites事件


需要写一个类,继承testing::Test,然后实现两个静态方法


1. SetUpTestCase() 方法在第一个TestCase之前执行。


2. TearDownTestCase() 方法在最后一个TestCase之后执行。


3.TestCase事件


TestCase事件是挂在每个案例执行前后的,实现方式和Test'Suites的几乎一样,不过需要实现的是SetUp方法和TearDown方法:


1. SetUp()方法在每个TestCase之前执行。


2. TearDown()方法在每个TestCase之后执行。


测试用例入口


int main(int argc,char *argv[])
{
    testing::InitGoogleTest(&argc,argv);
    return RUN_ALL_TESTS();
}


cmake工程中使用


find_package(GTest CONFIG REQUIRED)
target_link_libraries(${PROJECT_NAME} PRIVATE GTest::gtest GTest::gtest_main GTest::gmock GTest::gmock_main)


附个简单的cmake工程模板:


cmake_minimum_required(VERSION 3.12)
project(mygtest VERSION 0.0.1)
set(CMAKE_CXX_STANDARD 11)
####################  QT dependencies ####################
#set(CMAKE_CXX_STANDARD 11)
#set(CMAKE_AUTOMOC ON)
#set(CMAKE_AUTORCC ON)
#set(CMAKE_AUTOUIC ON)
#set(QT_VERSION 5)
#set(REQUIRED_LIBS Core)
#set(REQUIRED_LIBS_QUALIFIED Qt5::Core)
####################  set output directory ####################
set(BUILD_DIR ${CMAKE_CURRENT_SOURCE_DIR}/build)
set(LIB_DIR ${BUILD_DIR}/Release)
set(LIB_FIX)
if (CMAKE_BUILD_TYPE MATCHES "Debug")
    set(LIB_DIR ${BUILD_DIR}/Debug)
    set(LIB_FIX _d)
endif ()
get_filename_component(ABSOLUTE_PATH ${LIB_DIR} ABSOLUTE)
set(LIB_DIR ${ABSOLUTE_PATH})
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${LIB_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR}/lib)
set(CMAKE_PDB_OUTPUT_DIRECTORY ${LIB_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${LIB_DIR}/lib)
set(LIB_DIR_FIX ${LIB_DIR}/bin)
option(USE_VS_BUILD "use visual studio build." OFF)
if (USE_VS_BUILD)
    set(LIB_DIR_FIX ${LIB_DIR}/bin/Debug)
endif ()
####################  set include path ####################
set(SRC_PATH
        ${CMAKE_CURRENT_SOURCE_DIR}/
        )
include_directories(
        ${SRC_PATH}
        ${BUILD_DIR}/../include
)
add_definitions(
)
####################  scan source files ####################
foreach (path ${SRC_PATH})
    aux_source_directory(${path} SRC_FILES)
endforeach ()
####################  version config ####################
#configure_file(${BUILD_DIR}/../include/version.h.in ${CMAKE_CURRENT_BINARY_DIR}/plugin_version.h)
#include_directories(${CMAKE_CURRENT_BINARY_DIR})
#if (MSVC)
#    set(MY_VERSIONINFO_RC "${CMAKE_CURRENT_BINARY_DIR}/VersionInfo.rc")
#    configure_file("${CMAKE_CURRENT_SOURCE_DIR}/resource.rc.in"
#            "${MY_VERSIONINFO_RC}")
#endif ()
#add_library(${PROJECT_NAME} SHARED ${SRC_FILES} ${MY_VERSIONINFO_RC})
add_executable(${PROJECT_NAME} ${SRC_FILES})
####################  set target properties ####################
set_target_properties(${PROJECT_NAME} PROPERTIES DEBUG_POSTFIX _d)
####################  set target dependencies ####################
find_package(GTest CONFIG REQUIRED)
#find_package(Qt${QT_VERSION} COMPONENTS ${REQUIRED_LIBS} REQUIRED)
set(THIRD_LIBS
        #${REQUIRED_LIBS_QUALIFIED}
        #${LOGGING_LIB}
        )
target_link_libraries(${PROJECT_NAME} PRIVATE ${THIRD_LIBS})
target_link_libraries(${PROJECT_NAME} PRIVATE GTest::gtest GTest::gtest_main GTest::gmock GTest::gmock_main)


在clion的项目中还需要配置:


-DCMAKE_PREFIX_PATH=D:\Qt5.12.11\Qt5.12.11\5.12.11\msvc2015_64\lib\cmake -DCMAKE_TOOLCHAIN_FILE=F:\vcpkg\scripts\buildsystems\vcpkg.cmake -Wno-dev


若使用命令行下尝试,则推荐使用powershell脚本,附个示例:


$VcpkgPath = "F:/vcpkg/scripts/buildsystems/vcpkg.cmake"
#if (($result = Read-Host "Enter the full path of vcpkg.cmake[default: F:/vcpkg/scripts/buildsystems/vcpkg.cmake]") -eq '') {} else {$VcpkgPath=$result}
Write-Host "`n VcpkgPath: $VcpkgPath" -ForegroundColor Yellow
Push-Location 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools'    
cmd /c "vsvars32.bat&set" |
ForEach-Object {
  if ($_ -match "=") {
    $v = $_.split("="); set-item -force -path "ENV:\$($v[0])"  -value "$($v[1])"
  }
}
Pop-Location
write-host "`nVisual Studio 2015 Command Prompt variables set." -ForegroundColor Yellow
Write-Host "`n build for this module project." -ForegroundColor Green
cmake . -B build -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE="$VcpkgPath" -Wno-dev -G "NMake Makefiles" 
Set-Location build
nmake 
#nmake install
Set-Location ..


简单示例


#include<iostream>
using namespace std; 
#include<gtest/gtest.h>
class MyClass{
public:
    int add(int a,int b){
        return a+b;
    }
    int del(int a,int b){
        return a-b;
    }
};
//class MyClassTest: public testing::Test{}
class MyClassTest: public testing::TestWithParam<int>{
public:
    static void SetUpTestCase()
    {
        cout<<"SetUpTestCase"<<endl;
    }
    static void TearDownTestCase()
    {
        cout<<"TearDownTestCase"<<endl;
    }
    virtual void SetUp()   //TEST跑之前会执行SetUp
    {
        cout<<"SetUp"<<endl;
    }
    virtual void TearDown() //TEST跑完之后会执行TearDown
    {
        cout<<"TearDown"<<endl;
    }
    MyClass myClass;
};
INSTANTIATE_TEST_SUITE_P(PARAM,MyClassTest,testing::Values(3,5,7,9));
int Abs(int x)
{
     return x > 0 ? x : -x;
}
TEST(IsAbsTest,MyTest)
{
    ASSERT_TRUE(Abs(1) == 1) << "Abs(1)=1";  //ASSERT_TRUE期待结果是true,operator<<输出一些自定义的信息
    ASSERT_TRUE(Abs(-1) == 1) << "Abs(-1)=1";
    ASSERT_FALSE(Abs(-2) == -2);  //期待结果是false
    ASSERT_EQ(Abs(1),Abs(-1));
    ASSERT_NE(Abs(-1),0);
    ASSERT_LT(Abs(-1),2);
    ASSERT_GT(Abs(-1),0);
    ASSERT_LE(Abs(-1),2);
    ASSERT_GE(Abs(-1),0);
}
//此时使用的是TEST_P宏
TEST_P(MyClassTest,AddTest)
{
    auto out= myClass.add(1,2);
    //ASSERT_NE(out,3);
    int n = GetParam();
    ASSERT_EQ(out,3);
    ASSERT_EQ(out,n);
}
//此时使用的是TEST_F宏
TEST_F(MyClassTest,Add)
{
    auto out= myClass.add(1,2);
    ASSERT_EQ(out,3);
}
TEST_F(MyClassTest,del)
{
    ASSERT_EQ(myClass.del(4,3),1);
}
int main(int argc,char *argv[])
{
    testing::InitGoogleTest(&argc,argv);
    return RUN_ALL_TESTS();
}


运行结果:



引用


手把手教你使用gtest写单元测试(1/2) - 知乎


GTest 总结_HUSTER593的博客-CSDN博客_gtest


gtest的介绍和使用_linhai1028的博客-CSDN博客_gtest


玩转Google开源C++单元测试框架Google Test系列(gtest)之四 - 参数化 - CoderZh - 博客园


https://www.csdn.net/tags/NtjaAg2sNTM4MjMtYmxvZwO0O0OO0O0O.html


Google C++单元测试框架GoogleTest(总) - 超超boy - 博客园


编写优美的GTest测试案例 - CoderZh - 博客园

相关文章
|
4天前
|
Web App开发 IDE 测试技术
【专栏】深入理解自动化测试框架 Selenium 的核心组件
【4月更文挑战第27天】Selenium 是一款广泛使用的自动化测试框架,核心组件包括 WebDriver(与浏览器交互的接口,支持多浏览器测试),IDE(可视化的测试脚本录制和编辑工具)和 Grid(分布式测试,实现多机器并行测试)。通过这些组件,开发者能高效、稳定地进行自动化测试,但需注意浏览器兼容性、脚本维护和性能问题。理解并掌握这些组件的使用,能提升测试效率和质量。
|
1天前
|
数据管理 测试技术
深入理解自动化测试框架:以Selenium为例
【4月更文挑战第30天】 随着软件开发的快速发展,自动化测试已经成为保证软件质量和提升开发效率的重要手段。本文将深入探讨自动化测试框架的核心概念,并以广泛应用的开源工具Selenium为例,解析其架构、原理及在实际项目中的运用。通过实例分析与性能评估,旨在为读者提供一套系统的自动化测试解决方案,并探讨其在复杂应用场景下的优化策略。
|
1天前
|
敏捷开发 前端开发 JavaScript
深入理解自动化测试框架:以Selenium为例
【4月更文挑战第30天】 在现代软件开发过程中,自动化测试已成为确保产品质量和加快市场投放的关键步骤。本文聚焦于流行的自动化测试框架——Selenium,探讨其架构、核心组件以及如何有效地利用Selenium进行Web应用测试。通过分析真实案例,我们将揭示Selenium在实际项目中的应用优势与面临的挑战,并提出优化策略。文章的目的在于帮助测试工程师深入理解Selenium,提升其在复杂项目中的运用效率。
|
1天前
|
前端开发 IDE 数据可视化
深入理解与应用自动化测试框架Selenium的最佳实践
【4月更文挑战第30天】 本文将深入剖析自动化测试框架Selenium的核心原理,并结合最佳实践案例,探讨如何有效提升测试覆盖率和效率。文中不仅涉及Selenium的架构解析,还将提供针对性的策略来优化测试脚本,确保测试流程的稳定性与可靠性。通过实例演示,读者可以掌握如何在不同测试场景中灵活运用Selenium,以及如何处理常见的技术挑战。
|
1天前
|
JavaScript 安全 编译器
【TypeScript 技术专栏】TypeScript 与 Jest 测试框架
【4月更文挑战第30天】本文探讨了TypeScript与Jest测试框架的结合在确保代码质量和稳定性上的重要性。Jest以其易用性、内置断言库、快照测试和代码覆盖率分析等特点,为TypeScript提供全面的测试支持。两者结合能实现类型安全的测试,提高开发效率,并涵盖各种测试场景,包括异步操作。通过实际案例分析,展示了如何有效利用这两个工具提升测试质量和开发效率,为项目成功奠定基础。
|
1天前
|
敏捷开发 监控 前端开发
深入理解与应用自动化测试框架:以Selenium为例
【4月更文挑战第30天】 在软件开发的快速迭代周期中,质量保证(QA)团队面临持续的压力,需确保产品在每次发布时都达到预期的质量标准。为了应对这一挑战,自动化测试成为了关键工具,它不仅提高了测试效率,还确保了测试的一致性和可重复性。本文将探讨自动化测试框架Selenium的核心组件、工作原理及其在实际测试中的应用。通过分析Selenium的优势和面临的常见问题,我们将讨论如何有效地集成Selenium到现有的测试流程中,以及如何克服常见的技术障碍。我们的目标是为读者提供一个清晰的指南,帮助他们理解和利用自动化测试框架来优化他们的软件测试实践。
|
2天前
|
前端开发 JavaScript 测试技术
深入探索自动化测试框架:Selenium与Appium的对比分析
【4月更文挑战第29天】 在快速迭代的软件发展环境中,自动化测试已成为确保软件质量和加速产品上市的关键步骤。本文将重点探讨两种广泛使用的自动化测试框架——Selenium和Appium,通过对比它们的核心特性、适用场景及执行效率,为软件开发和测试团队提供选择指南。文章不仅分析了各自的技术架构和脚本语言支持,还讨论了它们在处理Web应用和移动应用测试时的优缺点,旨在帮助读者根据项目需求做出更加明智的选择。
|
3天前
|
测试技术 API 持续交付
深入理解自动化测试框架Selenium的设计与实现
【4月更文挑战第28天】 本文旨在深度剖析自动化测试框架Selenium的核心设计原理与实现机制。不同于传统的摘要概括,本文将通过具体实例和代码片段,详细阐述Selenium如何通过WebDriver接口与不同浏览器进行交互,以及其支持多种编程语言环境的设计理念。文章还将探讨Selenium Grid的配置和使用,展示其在分布式并行测试中的优势。最后,对Selenium在持续集成环境中的应用进行展望,为读者提供一种全新的视角来理解并运用Selenium。
|
4天前
|
敏捷开发 监控 Java
深入理解与应用软件自动化测试框架
【4月更文挑战第27天】 在软件开发的生命周期中,确保代码质量和功能的正确性是至关重要的。随着敏捷开发方法的普及和产品迭代速度的加快,传统的手动测试方法已经难以满足快速交付的需求。本文将重点讨论软件自动化测试框架的构建与实施,旨在为读者提供一种提高测试效率、确保测试质量的有效途径。我们将介绍自动化测试的基本概念、关键优势以及面临的挑战,并通过具体的案例分析,展示如何根据项目特点选择合适的测试框架,以及如何设计、执行和维护自动化测试脚本。
|
5天前
|
Web App开发 IDE 测试技术
深入理解自动化测试框架Selenium的设计与实践
【4月更文挑战第27天】在软件开发周期中,确保代码质量和功能正确性至关重要。随着敏捷开发的普及和持续集成/持续部署(CI/CD)的实践,自动化测试已成为现代开发工作流程的核心部分。本文将探讨一个广泛使用的开源自动化测试工具——Selenium,并剖析其设计原理、架构以及在实际中的应用。我们将通过具体案例分析,展示如何有效利用Selenium进行跨浏览器测试,并讨论在真实环境中可能遇到的挑战及解决方案。