[开发测试]【单元测试】Google Test（GTest）和Google Mock（GMock）--编辑中

目录

Gtest简介

局限性

入门例子

还可以打印信息

进阶：测试我们函数的API--ASSERT_*和EXPECT_*

TEST, TEST_F ?TEST_P的区别

ASSERT_*和EXPECT_* 说明

简单的测试例子

Test Fixtures(为多个测试使用相同的配置)

调用测试

编写main()函数

已知的限制

GMock简介

Gtest简介

GoogleTest 是 Google 的 C++ 测试和模拟框架，是库，提供了一些API接口，用于测试你的程序。

我们编写测试文件，里面调用GoogleTest的API 测试我们的函数。然后编译的时候把GoogleTest的库链接进来即可。

? Gtest是google开发的一个开源的C++测试框架，可在Linux, Windows,Mac多个平台上对C++源码进行测试，不仅支持单元测试，也支持其他类型测试。

一 基本概念

??? 使用gtest时，就是编写断言（assertions），断言语句会检测条件是否为真。一个断言可存在三种结果：success（成功），nonfatal failure（非致命失败）,或 fatal failure（致命失败）。当出现致命失败时，终止当前函数；否则程序继续执行。

??? Tests使用断言语句来检测代码的结果。如果一个test出现崩溃或有一个失败的断言，则该test是fails，否则是succeeds。

??? 一个test suite包括一个或多个tests。可以将多个tests分组到test suite中，以此反映所测试代码的结构。当一个test suite中的多个tests需要共享一些通用对象和子程序时，可将其放入一个test fixture class。

? 一个test program可包含多个test suites.

局限性

gtest 是线程安全的，但是这个线程安全仅仅在支持 pthread 的系统的可以。在其他系统中使用两个线程运行测试是不安全的，比如 windows。

入门例子

编译环境中安装Gtest，既编译Gtest的源码编出Gtest的库gtest，放到链接目录下（供后面测试代码链接它和调用它的API）

$ git clone https://github.com/google/googletest.git

$?cd?googletest

$?mkdir?build

$?cd?build

$ cmake ..

$?make

$?sudo?make?install

我们的工程文件（程序/函数）

mySrc.h

int?Foo(int?a,int?b);

mySrc.cpp

int?Foo(int?a,int?b)

{

???if(0 == a||0 == b)

???throw?"don't do that";

???int?c = a%b;

???if?(0 == c)

??{

?????return?b;

??}

??return?Foo(b,c);

}

编写单元测试工程（文件）

test.cpp?里面调用Gtest的API测试我们的函数/程序：

#include "mySrc.h"

#include <gtest/gtest.h>

#TEST 就是Gtest的API,用于测试我们的程序的函数FooTest等

TEST(FooTest,HandleNoneZeroInput)?

{

???EXPECT_EQ(2,Foo(4,10));

???EXPECT_EQ(6,Foo(30,18));

}

int?main(int?argc,char*argv[])

{

???testing::InitGoogleTest(&argc,argv);

???return?RUN_ALL_TESTS();

}

编译单元测试工程

$ g++ -std=c++11?test.cpp?mySrc.cpp?mySrc.h??-lgtest -lpthread? ./a.out

执行单元测试?

./a.out

摘自：Gtest学习系列一：Gtest安装与基本测试 ：https://www.cnblogs.com/yanqingyang/p/12732087.html

还可以打印信息

ASSERT_EQ(x.size(), y.size()) << "Vectors x and y are of unequal length";

for (int i = 0; i < x.size(); ++i) {
? EXPECT_EQ(x[i], y[i]) << "Vectors x and y differ at index " << i;
}

进阶：测试我们函数的API--ASSERT_*和EXPECT_*

TEST, TEST_F ?TEST_P的区别

TEST()??Example test

适合给static或全局函数或简单类编写单元测试时.

TEST_F()?.?Example test

测试夹具(Test Fixtures)：对多个测试使用相同的数据配置。多个测试来操作类似的数据，你可以使用测试夹具。它允许您为几个不同的测试重复使用相同的对象配置。

可以编写默认构造函数或SetUp（）函数来为几个测试准备（共同）对象。

如果需要，写一个析构函数或TearDown（）函数来释放你在SetUp（）中分配的任何资源。

更多详情见：Google C++单元测试框架GoogleTest---TestFixture使用 - 超超boy - 博客园

TEST_P()?

TEST_P()?当您想使用参数编写测试时，TEST_P（）非常有用。您可以使用test_P（）编写一个测试，而不是使用不同的参数值编写多个测试，test_P（）使用GetParam（）并可以使用INSTANTIATE_test_SUITE_P（）进行实例化。示例测试.?Example test

googletest - What is the difference between TEST, TEST_F and TEST_P? - Stack Overflow

TEST_F与TEST的区别是，TEST_F提供了一个初始化函数（SetUp）和一个清理函数(TearDown)，在TEST_F中使用的变量可以在初始化函数SetUp中初始化，在TearDown中销毁，并且所有的TEST_F是互相独立的，都是在初始化以后的状态开始运行，一个TEST_F不会影响另一个TEST_F所使用的数据，下面是一个例子。

//A.h
#ifndef A_H
#define A_H
class A
{
private:
　　int _a;
public:
　　A( int a );
　　~A( );
　　void add( int a );
　　int getA( );
};
#endif
A.cpp
#include "A.h"
A::A( int a ){
　　this->_a = a;
}
A::~A( ){
}
void A::add( int a ){
　　this->_a += a;
}
int A::getA( ){
　　return this->_a;
}

#-----------------------------------------
A_test.cpp
#include "A.h"
#include <gtest/gtest.h>


class A_test : public testing::Test
{

protected:
    　　A *_p_a;
    virtual void SetUp( )
    {
        //初始化函数
        this->_p_a = new A( 1 );
        　　
    }
    　virtual void TearDown( )
    {
        　 //清理函数
        　delete this->_p_a;
    }
};

//第一个测试，参数A_test是上面的那个类，第二个参数FirstAdd是测试名称
TEST_F( A_test, FirstAdd )
{
    EXPECT_EQ( 1, _p_a->getA( ) );
    _p_a->add( 3 );
    EXPECT_EQ( 4, _p_a->getA( ) );
}


//第二个测试
TEST_F( A_test, SecondAdd )
{

    　　EXPECT_EQ( 1, _p_a->getA( ) );
    　　_p_a->add( 5 );
    　　EXPECT_EQ( 6, _p_a->getA( ) );
}

/*
上面的两个测试都是在SetUp函数执行后的状态下执行，也就是说在执行任意一个TEST_F时 _p_a->_a 的值都是初始值1
*/
#-----------------------------------------
main.cpp
#include <gtest/gtest.h >

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

#-----------------------------------------

编译后执行的结果如下：
$ gtester main

TEST:
main... (pid = 13965)

[ == == == == == ] Running 2 tests from 1 test case.
[----------] Global test environment set - up.
[----------] 2 tests from A_test
[ RUN　　　] A_test.FirstAdd
[　　　 OK ] A_test.FirstAdd
[ RUN　　　] A_test.SecondAdd
[　　　 OK ] A_test.SecondAdd
[----------] Global test environment tear - down
[ == == == == == ] 2 tests from 1 test case ran.
[ PASSED ] 2 tests.
  PASS:
main

ASSERT_*和EXPECT_* 说明

不同点是：

ASSERT_*在断言失败时产生致命错误，并且终止当前函数。

EXPECT_*版本则产生非致命错误，且不会终止当前函数。

通常更倾向于使用EXPECT_*，因为这样能够允许在一个测试用例中报告多个错误。

如果断言继续下去没有意义的话，就应该使用ASSERT_*进行判断。

ASSERT_*立刻从当前函数返回，可能会跳过之后的清理代码，这将会导致空间泄漏。根据泄漏的性质，它可能值得修复，也可能不值得修复。因此，如果除了断言错误外还出现堆检查器错误，请记住检查这一点。

基本的断言

判断真假的断言

比较断言

这类断言用来比较两个值

断言参数的值必须是可比较的，否则会产生一个编译错误。当断言失败时，如果自定义的错误支持<<运算符，那么GTEST将会打印他们，否则将会尝试用其他的方式打印出他们。

用户自定义类型仅仅当定义了比较操作时，断言才能够比较的对象的大小，但是这不被Google的C++类型规范所提倡，这种情况下应当使用ASSERT_TRUE()或者EXPECT_TRUE()来进行判断。不过还是应当尽可能的使用ASSERT_EQ(actual, expected)，因为他能够在测试失败时告知actual和expected的值。

ASSERT_EQ()在比较指针时比较的是指针的值，当比较两个C风格的字符串时，将会比较他们是否有相同的内存地址，而不是有相同的值。因此在比较C风格字符串的时候应当使用ASSERT_STREQ()，但是在比较两个string对象的时候，应当使用ASSERT_EQ。

在进行指针的比较时应当使用*_EQ(ptr, nullptr)和*_NE(ptr, nullptr)代替*_EQ(ptr, NULL)和*_NE(ptr, NULL)，因为nullptr被定义了类型而NULL却没有。

当比较浮点数时应该使用浮点数断言来避免近似值导致的问题。

本节的宏定义对string和wstring都适用。

ps：2016年二月前的GTEST版本对*_EQ断言有着ASSERT_EQ(expected, actual)这样的顺序要求，但是新的*_EQ对两个参数顺序没有要求。

字符串比较

这节的断言用来比较C语言风格的字符串，在比较两个string对象时，应该使用EXPECT_EQ,EXPECT_NE。

注意：“CASE”表明忽略大小写，一个NULL指针和空字符串不一样

简单的测试例子

创建一个测试：

1. 使用TEST()宏定义来定义和命名一个测试函数，这些宏就是没有返回值的普通C++函数。
2. 在这个函数中，可以包含任何有效的c++语句中，使用各种GTEST断言来检查值。
3. 测试结果由断言决定；如果测试中的任何断言失败(致命或非致命)，或者测试崩溃，则整个测试失败。

TEST(TestSuiteName, TestName) {
  ... test body ...
}

TEST()的第一个参数是测试套件（Test Suite）的名称，第二个参数是这个测试套件中该测试（Test）的名称。两种名称都必须是合法的C++标识符，并且不能包含任何下划线_。不同测试套件中的测试可以有相同的名字。

举个例子，被测函数是一个简单的斐波那契函数：

int Factorial(int n);  // Returns the factorial of n

一个测试可以写成：

// Tests factorial of 0.
TEST(FactorialTest, HandlesZeroInput) {
  EXPECT_EQ(Factorial(0), 1);
}

// Tests factorial of positive numbers.
TEST(FactorialTest, HandlesPositiveInput) {
  EXPECT_EQ(Factorial(1), 1);
  EXPECT_EQ(Factorial(2), 2);
  EXPECT_EQ(Factorial(3), 6);
  EXPECT_EQ(Factorial(8), 40320);
}

逻辑上来说，相关的测试应该在同一个测试套件（Test Suite）中。在上述的例子中，有两个测试HandlesZeroInput和HandlesPositiveInput，他们属于同一个测试套件FactorialTest。

Test Fixtures(为多个测试使用相同的配置)

当两个或更多的测试需要使用相似的数据时，可以使用Test Fixture。这可以对不同的测试重用相同的数据对象配置。

创建一个fixture：

1. 从::testing::Test派生出一个类。用protected:开始它的类主体，因为需要从子类访问fixture成员。
2. 在类中声明所有准备使用的对象
3. 如果需要，可以编写一个默认构造函数或SetUp()函数来为每个测试准备对象。常见的错误是将SetUp()拼写为Setup()，在c++ 11中可以使用override来确保拼写正确。
4. 如有必要，编写一个析构函数或TearDown()函数以释放您在SetUp()中分配的所有资源。 若要了解何时应使用构造函数/析构函数以及何时应使用SetUp()/ TearDown()，请阅读[FAQ][www.baidu.com]。
5. 如果需要，定义要共享的测试的子程序。

当使用fixture时，使用TEST_F()代替TEST()，因为TEST_F()允许你在Test Fixture中获取对象和子程序：

TEST_F(TestFixtureName, TestName) {
  ... test body ...
}

和TEST()类似，第一个参数是测试套件的名字，但是TEST_F()的这个参数必须和Test Fixture类的名字相同。还需要在使用Test Fixture对象之前定义这个Test Fixture类，否则会导致编译错误virtual outside class declaration。

对于每个TEST_F()来说，GTEST在运行时都会创建一个新的test fixture对象，并且通过SetUp()立刻初始化这个对象，再运行测试，结束后通过调用TearDown()来进行清理工作，最后将删除这个test fixture对象。注意，在同一个测试套件中的不同测试拥有不同的test fixture对象，GTEST在新建下一个test fixture对象时总是会先删除上一个test fixture对象，并且不会在多个不同的测试中重用一个test fixture对象。所以如果任何测试改变了它的test fixture对象，并不会影响其他测试的test fixture对象。

下面用对一个FIFO队列类Queue编写测试，他有以下接口：

template <typename E>  // E is the element type.
class Queue {
 public:
  Queue();
  void Enqueue(const E& element);
  E* Dequeue();  // Returns NULL if the queue is empty.
  size_t size() const;
  ...
};

定义一个fixture类。按照惯例，应该给它起一个FooTest的名字，其中Foo是被测试的类。

class QueueTest : public ::testing::Test {
 protected:
  void SetUp() override {
     q1_.Enqueue(1);
     q2_.Enqueue(2);
     q2_.Enqueue(3);
  }

  // void TearDown() override {}

  Queue<int> q0_;
  Queue<int> q1_;
  Queue<int> q2_;
};

在这个例子中，不需要TearDown()函数，因为析构器已经完成了析构工作，不需要再进行清理。

TEST_F(QueueTest, IsEmptyInitially) {
  EXPECT_EQ(q0_.size(), 0);
}

TEST_F(QueueTest, DequeueWorks) {
  int* n = q0_.Dequeue();
  EXPECT_EQ(n, nullptr);

  n = q1_.Dequeue();
  ASSERT_NE(n, nullptr);
  EXPECT_EQ(*n, 1);
  EXPECT_EQ(q1_.size(), 0);
  delete n;

  n = q2_.Dequeue();
  ASSERT_NE(n, nullptr);
  EXPECT_EQ(*n, 2);
  EXPECT_EQ(q2_.size(), 1);
  delete n;
}

上面使用了ASSERT_*和EXPECT_*断言。当希望测试在断言失败后继续显示更多错误时使用EXPECT_*，而在失败后继续运行测试没有意义则使用ASSERT_*。例如，Dequeue测试中的第二个断言是ASSERT_NE(nullptr, n)，因为我们稍后需要对指针n进行解引用，这将在n的值为NULL时导致段错误。

当测试运行时，以下步骤将会发生：

1. GTEST构建一个QueueTest对象t1
2. t1.SetUp()初始化t1
3. 第一个测试在t1上运行
4. t1.TearDown()在第一个测试结束时进行清理
5. 析构t1
6. 在进行另外一个QueueTest对象测试DequeueWorks测试时，重复上述步骤

调用测试

TEST()和TEST_F()向googletest隐式注册其测试。与许多其他C ++测试框架不同，不必重新列出所有已定义的测试即可运行它们。

定义测试后，可以使用RUN_ALL_TESTS()运行它们，如果所有测试成功，将返回0，否则返回1。RUN_ALL_TESTS()在链接单元中运行所有测试，它们可以来自不同的测试套件，甚至来自不同的源文件。

当调用RUN_ALL_TESTS()宏时：

• 保存所有GTEST标志的状态
• 为第一个测试创建一个test fixture对象
• 通过SetUp()初始化这个对象
• 在fixture对象上运行测试
• 通过TearDown()函数进行清理
• 删除fixture对象
• 恢复所有GTEST标志的状态
• 重复上述步骤直到测试结束

当一个致命性的错误发生时，后续的步骤将会被跳过。

重要说明：一定不能忽略RUN_ALL_TESTS()的返回值，否则会出现编译器错误。 这种设计的基本原理是，自动化测试服务将根据其退出代码（而不是根据其stdout / stderr输出）来确定测试是否通过。 因此main()函数必须返回RUN_ALL_TESTS()的值。

另外，您应该只调用一次RUN_ALL_TESTS()。 多次调用它会与某些高级googletest功能（例如线程安全的死亡测试）发生冲突，因此不被支持。

编写main()函数

gtest_main库提供了一个合适的程序入口点，通过链接gtest_main动态库而不是gtest库，大多用户无需编写他们自己的main函数(Google Test提供了main()函数的基本实现。如果适合你的需求，则只需将测试与gtest_main库链接就可以了。)。本节的其余部分仅适用于需要在测试运行前做一些自定义的事情，而这些事情不能在test fixture和测试套件的框架内表达。

如果您编写自己的main()函数，则该函数应返回RUN_ALL_TESTS()的值。

下面是一个模板：

#include "this/package/foo.h"

#include "gtest/gtest.h"

namespace my {
namespace project {
namespace {

// The fixture for testing class Foo.
class FooTest : public ::testing::Test {
 protected:
  // You can remove any or all of the following functions if their bodies would
  // be empty.

  FooTest() {
     // You can do set-up work for each test here.
  }

  ~FooTest() override {
     // You can do clean-up work that doesn't throw exceptions here.
  }

  // If the constructor and destructor are not enough for setting up
  // and cleaning up each test, you can define the following methods:

  void SetUp() override {
     // Code here will be called immediately after the constructor (right
     // before each test).
  }

  void TearDown() override {
     // Code here will be called immediately after each test (right
     // before the destructor).
  }

  // Class members declared here can be used by all tests in the test suite
  // for Foo.
};

// Tests that the Foo::Bar() method does Abc.
TEST_F(FooTest, MethodBarDoesAbc) {
  const std::string input_filepath = "this/package/testdata/myinputfile.dat";
  const std::string output_filepath = "this/package/testdata/myoutputfile.dat";
  Foo f;
  EXPECT_EQ(f.Bar(input_filepath, output_filepath), 0);
}

// Tests that Foo does Xyz.
TEST_F(FooTest, DoesXyz) {
  // Exercises the Xyz feature of Foo.
}

}  // namespace
}  // namespace project
}  // namespace my

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

:: testing :: InitGoogleTest()函数解析命令行中的googletest标志，并删除所有可识别的标志。这允许用户通过各种标志控制测试程序的行为，将在AdvancedGuide中介绍这些标志。 注意，必须在调用RUN_ALL_TESTS()之前调用该函数，否则标志将无法正确初始化。

已知的限制

GTEST被设计成线程安全的。在使用pthread的系统上，GTEST的实现是线程安全的，而在其他系统(如Windows)上多线程并发使用Google Test的断言并不安全。一般情况下断言都是在主线程中进行的，因此在绝大多数测试中这并不会产生问题。

2人点赞

C++测试框架--GTEST

作者：愿以光散黑
链接：https://www.jianshu.com/p/c7c702c0abb9
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

GMock简介

GoogleMock是个很强大的东西，测试一个模块的时候，可能涉及到和其他模块交互，可以将模块之间的接口mock起来，模拟交互过程。

1. Makefile里面需要加入 -lgmock才能正常连接

?AM_LDFLAGS=-lpthread -lc -lm -lrt -lgtest -lgmock?

2. 可以手工生成Mock类，也可以使用脚本生成

手工：

class ObProject: public ObSingleChildPhyOperator
{ ??
? ?public:
? ? ? ? ObProject();
? ? ? ? virtual ~ObProject();
? ? ? ? void reset(){};
?
?
? ? ? ? int add_output_column(const ObSqlExpression& expr);
? ? ? ? virtual int open();
? ? ? ? virtual int close();
? ? ? ? virtual int get_next_row(const common::ObRow *&row);
? ? ? ? virtual int64_t to_string(char* buf, const int64_t buf_len) const;
? ? ? ? ....
?};
?
class MockObProject : public ObProject
?
{
? public:
? MOCK_METHOD0(open, int());
? MOCK_METHOD0(close, int());
? MOCK_METHOD1(add_output_column, int(const ObSqlExpression &expr));
};

脚本：
需要mock ob_ms_tablet_location_proxy.h中的ObMergerLocationCacheProxy类，方法如下：

?gmock_installed_dir/scripts/generator/gmock_gen.py ob_ms_tablet_location_proxy.h ObMergerLocationCacheProxy

3. 一个类中，只有virtual的member funciton能被mock（试验得到的结论），调用被mock的member function，function行为变成mocked behavior，调用类中没有被mock的member function，function行为与原类相同，不被mock改变。
ps，写了一个简单类，不是virtual居然也能被mock，奇怪。。。。在一个复杂类中，必须是virtual的才能被mock。 这些是实验得到的结论。

从理论上分析，应该必须是virtual才可以。所以，确定哪些函数要被mock，然后在头文件中将其virtual化。不然可别说我没有预先告诉你哦；)

4. 一个被Mock的函数，如果没有在EXPECT_CALL中指定expected behavior，系统将会为其指派默认行为（什么都不做，返回0），并且在屏幕上打印WARNING：

GMOCK WARNING:
Uninteresting mock function call - returning default value.
? ? Function call: get_next_row(@0x7fff51a6b888 0x30c51529e0)
? ? ? ? ? Returns: 0
Stack trace:

摘抄自：https://blog.csdn.net/maray/article/details/7750617

创作打卡挑战赛

赢取流量/现金/CSDN周边激励大奖