正式工作之后，公司對于單元測試要求比較嚴(yán)格。（筆者之前比較懶，一般很少寫完整的單測~~）。作為一個合格的開發(fā)工程師，需要為所編寫代碼編寫適量的單元測試是十分必要的，在實際進行的開發(fā)工作之中，TDD（Test drivern development) 是一種經(jīng)過實踐可行的開發(fā)方式。編寫單元測試可以幫助我們在開發(fā)階段就發(fā)現(xiàn)錯誤，并且保證新的修改沒有破壞已有的程序邏輯。 在 C++之中，常用的測試框架有 Gtest，Boost test，CPPUint 等。正是由于 Gmock 的加持，讓 Gtest 在多種測試框架之中脫穎而出。今天筆者在這里要和大家聊聊的就是目前我司主力在使用的Gtest，以及配套的 Gmock，通過兩者的配合使用，相信能夠搞定絕大多數(shù)的測試場景了。

1.Gtest 的安裝

筆者目前使用的系統(tǒng)是Deepin 15.6，是基于 Debian jessie的一款國內(nèi)發(fā)行版。安裝 Gtest 和 GMock 十分簡單：

sudo apt-get install libgtest-dev libgmock-dev 

其他發(fā)行版如：Ubuntu，Centos 應(yīng)該也可以通過自帶的包管理軟件就可以完成安裝了。但是如果包管理軟件之中沒有帶上對應(yīng)的開發(fā)包，也可以選擇編譯安裝：

• 下載源碼

 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 之中鏈接對應(yīng)的靜態(tài)庫，就可以利用 Gtest 進行單元測試了。

2.Gtest 的使用

Gtest 十分容易上手，通過其中的定義的宏就可以輕松實現(xiàn)要進行單元測試。并且其中每個單元測試都會計算出對應(yīng)執(zhí)行時間，可以通過執(zhí)行時間來分析代碼的執(zhí)行效率。

測試函數(shù)TEST

先舉個簡單的栗子，假如現(xiàn)在我們需要測試一下函數(shù)來判斷質(zhì)數(shù)，代碼如下:

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;
}

現(xiàn)在我們用 Gtest 對這個函數(shù)進行測試，TEST的宏定義代表了會被RUN_ALL_TESTS執(zhí)行的測試函數(shù)。在 Gtest 之中提供了兩類斷言ASSERT_*系列和EXPECT_*系列。兩者的區(qū)別就在于，ASSERT 失敗之后就不會運行后續(xù)的測試了，但是 EXPECT 雖然失敗，但是不影響后續(xù)測試的進行?？雌饋?strong>EXPECT會更加靈活一些，尤其是需要釋放一些資源或執(zhí)行一些其他邏輯時，更適合用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 初始化測試框架，必須在運行測試之前調(diào)用 RUN_ALL_TESTS 會運行所有由TEST 宏定義的測試。測試結(jié)果如下圖所示：我們定義的is_true和 is_false同屬同一個測試 case：test_prime，并且成功通過了測試。

測試結(jié)果

判斷宏

Gtest 提供了多種的判斷宏，包括字符串的判斷，數(shù)值判斷等等，具體的細節(jié)可以參照 Gtest 的官方文檔，筆者這里不再贅述。

測試函數(shù)TEST_F

很多時候，我們進行一些測試的時候需要進行資源初始化工作，進行資源復(fù)用，最后回收資源。這樣的場景就適合使用 TEST_F的宏來進行測試。TEST_F適用于多種測試場景需要相同數(shù)據(jù)配置的情況，利用了 C++繼承類來實現(xiàn)對父類方法的測試。舉個例子，筆者實現(xiàn)了一個跳表，下面是對跳表進行測試的代碼：

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類。同時要實現(xiàn)對應(yīng)的 SetUp與TearDown方法，SetUp方式執(zhí)行資源的初始化操作，而TearDown則負(fù)責(zé)資源的釋放。需要注意的是，上述代碼我們測試了跳表的search,remove,insert方法，而每個測試是獨立的進行的。也就是每個測試執(zhí)行時都會運行對應(yīng)的SetUp和 TearDown方法。

命令行參數(shù)

編譯生成二進制的測試執(zhí)行文件之后，直接運行就可以執(zhí)行單元測試了。但是 Gtest 提供了一些命令行參數(shù)來幫助我們更好的使用，下面介紹一下筆者常用的幾個命令行參數(shù)：

• --gtest_list_tests
  列出所有需要執(zhí)行的測試，但是并不執(zhí)行。
• --gtest_filter
  對所執(zhí)行的測試進行過濾，支持通配符
  ? 單個字符
  * 任意字符
  - 排除
  ./test --gtest_filter=SkTest.*-SkTest.insert 表示運行所有名為SkTest的案例，排除了SkTest.insert這個案例。
• --gtest_repeat=[count]
  設(shè)置測試重復(fù)運行的次數(shù)，其中-1表示無限執(zhí)行。

3.Gmock 的使用

上述 Gtest 的使用應(yīng)該能夠滿足絕大多數(shù)小型項目的測試場景了。但是對于一些涉及數(shù)據(jù)庫交互，網(wǎng)絡(luò)通信的大型項目的測試場景，我們很難仿真一個真實的環(huán)境進行單元測試。所以這時就需要引入** Mock Objects **（模擬對象）來模擬程序的一部分來構(gòu)造測試場景。Mock Object模擬了實際對象的接口，通過一些簡單的代碼模擬實際對象部分的邏輯，實現(xiàn)起來簡單很多。通過 Mock object 的方式可以更好的提升項目的模塊化程度，隔離不同的程序邏輯或環(huán)境。

至于如何使用 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，后面的數(shù)字代表了模擬函數(shù)的參數(shù)個數(shù)，如MOCK_METHOD0，MOCK_METHOD1。它接受兩個參數(shù)：

• 參數(shù)1，方法名稱。
• 參數(shù)2，函數(shù)的指針的定義

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&));
};

通過這個宏定義，我們已經(jīng)初步模擬出對應(yīng)的方法了。接下來我們需要告訴 Mock Object 被調(diào)用時的正確行為。

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 的對應(yīng)行為，其中 WillOnce代表調(diào)用一次返回的結(jié)果。通過鏈?zhǔn)秸{(diào)用的方式，我們就可以構(gòu)造出所有我們想要的模擬結(jié)果。當(dāng)然如果每次調(diào)用的結(jié)果都一樣，這里也可以使用WillRepeatedly直接返回對應(yīng)的結(jié)果。由上述代碼可以看到，這里我們用寥寥數(shù)十行代碼就模擬出了一個 KV 存儲引擎，可見 Gmock 的強大。

這里要注意，在通過 Gmock 來編寫 Mock Object 時，能夠模擬的方法是對于原抽象類之中的virtual 方法。這個是因為 C++只有通過virtual的方式才能實現(xiàn)子類覆寫的多態(tài)，這一點在編寫代碼進行抽象和編寫 Mock Object 的時候需要多加注意。

4.小結(jié)

通過Gtest 與 Gmock 的使用，能夠覆蓋絕大多數(shù)進行 C++ 單元測試的場景，同時也減少了我們編寫單元測試的工作。筆者希望通過本篇文章來拋磚引玉，希望大家多寫單測。在筆者實際的工作經(jīng)驗之中，單測給項目帶來的影響是極其正面的，一定要堅持寫單測，堅持寫單測，堅持寫單測~~~！??！