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++ 單元測試的場景，同時也減少了我們編寫單元測試的工作。筆者希望通過本篇文章來拋磚引玉，希望大家多寫單測。在筆者實際的工作經驗之中，單測給項目帶來的影響是極其正面的，一定要堅持寫單測，堅持寫單測，堅持寫單測~~~！！！
C++霧中風景番外篇2：Gtest 與 Gmock，聊聊C++的單元測試