C++雾中风景番外篇2:Gtest 与 Gmock,聊聊C++的单元测试
正式工作之后,公司对于单元测试要求比较严格。(笔者之前比较懒,一般很少写完整的单测~~)。作为一个合格的开发工程师,需要为所编写代码编写适量的单元测试是十分必要的,在实际进行的开发工作之中,TDD(Test drivern development) 是一种经过实践可行的开发方式。编写单元测试可以帮助我们在开发阶段就发现错误,并且保证新的修改没有破坏已有的程序逻辑。 在 C++之中,常用的测试框架有 Gtest,Boost test,CPPUint 等。正是由于 Gmock 的加持,让 Gtest 在多种测试框架之中脱颖而出。今天笔者在这里要和大家聊聊的就是目前我司主力在使用的Gtest,以及配套的 Gmock,通过两者的配合使用,相信能够搞定绝大多数的测试场景了。
1.Gtest 的安装
笔者目前使用的系统是Deepin 15.6,是基于 Debian jessie的一款国内发行版。安装 Gtest 和 GMock 十分简单:
sudo apt-get install libgtest-dev libgmock-dev
其他发行版如:Ubuntu,Centos 应该也可以通过自带的包管理软件就可以完成安装了。但是如果包管理软件之中没有带上对应的开发包,也可以选择编译安装:
- 下载源码
git clone https://github.com/google/googletest
- 用 CMake 生成 Makefile之后直接 make 编译
cd build && cmake .. && make -j 2
- 最后进行安装
sudo make install
之后只要在/usr/include路径下找到gtest.h,gmock.h就说明我们安装成功了。之后只需要在 CMake 之中链接对应的静态库,就可以利用 Gtest 进行单元测试了。
2.Gtest 的使用
Gtest 十分容易上手,通过其中的定义的宏就可以轻松实现要进行单元测试。并且其中每个单元测试都会计算出对应执行时间,可以通过执行时间来分析代码的执行效率。
测试函数TEST
先举个简单的栗子,假如现在我们需要测试一下函数来判断质数,代码如下:
bool is_prime(int num) { if (num < 2) return false; for(int i = 2; i <= sqrt(num) + 1; i++) { if (num % i == 0) return false; } return true; }
现在我们用 Gtest 对这个函数进行测试,TEST的宏定义代表了会被RUN_ALL_TESTS执行的测试函数。在 Gtest 之中提供了两类断言ASSERT_*系列和EXPECT_*系列。两者的区别就在于,ASSERT 失败之后就不会运行后续的测试了,但是 EXPECT 虽然失败,但是不影响后续测试的进行。看起来EXPECT会更加灵活一些,尤其是需要释放一些资源或执行一些其他逻辑时,更适合用EXPECT。
TEST(test_prime, is_true) { EXPECT_TRUE(is_prime(5)); ASSERT_TRUE(is_prime(5)); EXPECT_TRUE(is_prime(3)); } TEST(test_prime, is_false) { ASSERT_FALSE(is_prime(4)); EXPECT_FALSE(is_prime(4)); } int main(int argc,char *argv[]) { testing::InitGoogleTest(&argc, argv); RUN_ALL_TESTS(); }
testing::InitGoogleTest 初始化测试框架,必须在运行测试之前调用 RUN_ALL_TESTS 会运行所有由TEST 宏定义的测试。测试结果如下图所示:我们定义的is_true和 is_false同属同一个测试 case:test_prime,并且成功通过了测试。
上面我们使用了这TRUE 与 FALSE 的判断宏:
Gtest 提供了多种的判断宏,包括字符串的判断,数值判断等等,具体的细节可以参照 Gtest 的官方文档,笔者这里不再赘述。
测试函数TEST_F
很多时候,我们进行一些测试的时候需要进行资源初始化工作,进行资源复用,最后回收资源。这样的场景就适合使用 TEST_F的宏来进行测试。TEST_F适用于多种测试场景需要相同数据配置的情况,利用了 C++继承类来实现对父类方法的测试。举个例子,笔者实现了一个跳表,下面是对跳表进行测试的代码:
class Test_Skiplist : public testing::Test { public: virtual void SetUp() { std::cout << "Set Up Test" << std::endl; _sl->load(); } virtual void TearDown() { std::cout << "Tear Down Test" << std::endl; _sl->dump(); } ~Test_Skiplist(){}; SkipList* _sl = new SkipList(); }; TEST_F(Test_Skiplist, insert) { std::string test_string("happen"); ASSERT_EQ(_sl->insert("1", test_string.c_str(), test_string.size()), Status::SUCCESS); test_string = "lee"; ASSERT_EQ(_sl->insert("2", test_string.c_str(), test_string.size()), Status::SUCCESS); uint64_t data64 = 50; ASSERT_EQ(_sl->insert("50", reinterpret_cast<char *>(&data64), 8), Status::SUCCESS); uint32_t data32 = 20; ASSERT_EQ(_sl->insert("20", reinterpret_cast<char *>(&data32), 4), Status::SUCCESS); } TEST_F(Test_Skiplist, search) { ASSERT_EQ(_sl->search("1")->value_size, 6); ASSERT_STREQ(std::string(_sl->search("1")->value.get()).c_str(), "happen"); ASSERT_EQ(_sl->search("3"), nullptr); } TEST_F(Test_Skiplist, remove) { ASSERT_EQ(_sl->remove("1"), Status::SUCCESS); ASSERT_EQ(_sl->remove("1"), Status::FAIL); ASSERT_EQ(_sl->search("1"), nullptr); }
由上述代码可以看到,通过 TEST_F进行的测试类需要继承testing::Test类。同时要实现对应的 SetUp与TearDown方法,SetUp方式执行资源的初始化操作,而TearDown则负责资源的释放。需要注意的是,上述代码我们测试了跳表的search,remove,insert方法,而每个测试是独立的进行的。也就是每个测试执行时都会运行对应的SetUp和 TearDown方法。
命令行参数
编译生成二进制的测试执行文件之后,直接运行就可以执行单元测试了。但是 Gtest 提供了一些命令行参数来帮助我们更好的使用,下面介绍一下笔者常用的几个命令行参数:
- --gtest_list_tests
列出所有需要执行的测试,但是并不执行。 - --gtest_filter
对所执行的测试进行过滤,支持通配符
? 单个字符
* 任意字符
- 排除
./test --gtest_filter=SkTest.*-SkTest.insert 表示运行所有名为SkTest的案例,排除了SkTest.insert这个案例。
- --gtest_repeat=[count]
设置测试重复运行的次数,其中-1表示无限执行。
3.Gmock 的使用
上述 Gtest 的使用应该能够满足绝大多数小型项目的测试场景了。但是对于一些涉及数据库交互,网络通信的大型项目的测试场景,我们很难仿真一个真实的环境进行单元测试。所以这时就需要引入 Mock Objects (模拟对象)来模拟程序的一部分来构造测试场景。Mock Object模拟了实际对象的接口,通过一些简单的代码模拟实际对象部分的逻辑,实现起来简单很多。通过 Mock object 的方式可以更好的提升项目的模块化程度,隔离不同的程序逻辑或环境。
至于如何使用 Mock Object 呢?这里要引出本章的主角 Gmock 了,接下来笔者将编写一个简要的 Mock对象并进行单元测试,来展示一下 GMock 的用法。这里我们用 Gmock 模拟一个 kv 存储引擎,并运行一些简单的测试逻辑。下面的代码是我们要模拟的 kv 存储引擎的头文件:
#ifndef LDB_KVDB_MOCK_H #define LDB_KVDB_MOCK_H class KVDB { public: std::string get(const std::string &key) const; Status set(const std::string &key, const std::string &value); Status remove(const std::string &key); }; #endif //LDB_KVDB_MOCK_H
然后我们需要定义个 Mock 类来继承 KVDB,并且定义需要模拟的方法:get, set, remove。这里我们用到了宏定义 MOCK_METHOD,后面的数字代表了模拟函数的参数个数,如MOCK_METHOD0,MOCK_METHOD1。它接受两个参数:
- 参数1,方法名称。
- 参数2,函数的指针的定义
class MockKVDB : public KVDB { public: MockKVDB() { } MOCK_METHOD1(remove, Status(const std::string&)); MOCK_METHOD2(set, Status(const std::string&, const std::string&)); MOCK_METHOD1(get, std::string (const std::string&)); };
通过这个宏定义,我们已经初步模拟出对应的方法了。接下来我们需要告诉 Mock Object 被调用时的正确行为。
TEST_F(TestKVDB, setstr) { EXPECT_CALL(*kvdb, set(_,_)).WillRepeatedly(Return(Status::SUCCESS)); ASSERT_EQ(kvdb->set("1", "happen"), Status::SUCCESS); ASSERT_EQ(kvdb->set("2", "lee"), Status::SUCCESS); ASSERT_EQ(kvdb->set("happen", "1"), Status::SUCCESS); ASSERT_EQ(kvdb->set("lee", "2"), Status::SUCCESS); } TEST_F(TestKVDB, getstr) { EXPECT_CALL(*kvdb, get(_)) \ .WillOnce(Return("happen")) .WillOnce(Return("lee")) .WillOnce(Return("1")) .WillOnce(Return("2")); ASSERT_STREQ(kvdb->get("1").c_str(), "happen"); ASSERT_STREQ(kvdb->get("2").c_str(), "lee"); ASSERT_STREQ(kvdb->get("happen").c_str(), "1"); ASSERT_STREQ(kvdb->get("lee").c_str(), "2"); } TEST_F(TestKVDB, remove) { EXPECT_CALL(*kvdb, remove(_)).WillOnce(Return(Status::SUCCESS)). WillOnce(Return(Status::FAIL)); EXPECT_CALL(*kvdb, get(_)) \ .WillOnce(Return("")); ASSERT_EQ(kvdb->remove("1"), Status::SUCCESS); ASSERT_EQ(kvdb->get("1"), ""); ASSERT_EQ(kvdb->remove("1"), Status::FAIL); }
由上述代码可以了解,这里通过了EXPECT_CALL来指定 Mock Object 的对应行为,其中 WillOnce代表调用一次返回的结果。通过链式调用的方式,我们就可以构造出所有我们想要的模拟结果。当然如果每次调用的结果都一样,这里也可以使用WillRepeatedly直接返回对应的结果。由上述代码可以看到,这里我们用寥寥数十行代码就模拟出了一个 KV 存储引擎,可见 Gmock 的强大。
这里要注意,在通过 Gmock 来编写 Mock Object 时,能够模拟的方法是对于原抽象类之中的virtual 方法。这个是因为 C++只有通过virtual的方式才能实现子类覆写的多态,这一点在编写代码进行抽象和编写 Mock Object 的时候需要多加注意。
4.小结
通过Gtest 与 Gmock 的使用,能够覆盖绝大多数进行 C++ 单元测试的场景,同时也减少了我们编写单元测试的工作。笔者希望通过本篇文章来抛砖引玉,希望大家多写单测。在笔者实际的工作经验之中,单测给项目带来的影响是极其正面的,一定要坚持写单测,坚持写单测,坚持写单测~~~!!!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【剖析 | SOFARPC 框架】之SOFARPC 连接管理与心跳剖析
前言 在 RPC 调用过程中,我们经常会和多个服务端进行远程调用,如果在每次调用的时候,都进行 TCP连接,会对 RPC的性能有比较大的影响,因此,实际的场景中,我们经常要对连接进行管理和保持。 SOFARPC应用心跳包以及断线重连实现,结合系统tcp-keepalive机制,来实现对RPC连接的管理和保持。 连接管理 首先我们将会介绍连接管理相关的一些背景知识。 长连接和短连接 短连接,一般是指客户端向服务端发起连接请求。连接建立后,发送数据,接收服务端数据返回,然后触发连接断开,下次再重新重复以上过程。 长连接,则是在建立连接后,发送数据,接收数据,但是不主动断开,并且主动通过心跳等机制来维持这个连接可用,当再次有数据发送请求时,不需要进行建立连接的过程。 一般的,长连接多用于数据发送频繁,点对点的通讯,因为每个TCP连接都需要进行握手,这是
- 下一篇
Spring Boot(03)——自动配置
Spring Boot 自动配置 Spring Boot的自动配置功能会根据Classpath中的Class为我们自动创建相应的bean。比如当classpath下存在MongoClient.class和MongoTemplate.class时就会进行Spring Data MongoDB的配置。这是通过MongoDataAutoConfiguration类配置的。下面是MongoDataAutoConfiguration类的定义,可以看到上面使用了@Configuration注解定义,且通过@ConditionalOnClass注解指定了只有在存在MongoClient.class和MongoTemplate.class时才会生效。@EnableConfigurationProperties指定了可以使用的配置属性类,Spring Boot会自动生成对应类型的bean,以供我们在自动配置类中进行依赖注入。@AutoConfigureAfter定义了该自动配置类生效的位置,下面代码指定了将在MongoAutoConfiguration配置类之后生效。 @Configuration @C...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- 设置Eclipse缩进为4个空格,增强代码规范
- Mario游戏-低调大师作品
- MySQL8.0.19开启GTID主从同步CentOS8
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Redis,开启缓存,提高访问速度
- CentOS关闭SELinux安全模块