linux環境編程(1): 實現一個單元測試框架

寫在前面在開發的過程中，大多數人都需要對代碼進行測試。目前對於c/c++項目，可以採用google的gtest框架，除此之外在github上搜索之後可以發現很多其他類似功能的項目。但把別人的輪子直接拿來用，終究比不過自己造一個同樣功能的輪子更有成就感。作為“linux環境編程”系列文章的第一篇，本 ...

寫在前面

在開發的過程中，大多數人都需要對代碼進行測試。目前對於c/c++項目，可以採用google的gtest框架，除此之外在github上搜索之後可以發現很多其他類似功能的項目。但把別人的輪子直接拿來用，終究比不過自己造一個同樣功能的輪子更有成就感。作為“linux環境編程”系列文章的第一篇，本篇文章記錄瞭如何用較少的代碼實現一個可用的單元測試框架，這個測試框架將一直在後續系列文章中的代碼實例環節使用，並且在使用過程中不斷完善和改進。相比於文字說明，我相信有人更喜歡直接看代碼實現，所以這裡先放一個github傳送門。

需求來源

先給項目取個名字吧，畢竟命名是最困難的環節了:P. 這個測試框架一句話可以概括為"a simple unit test framework for c programming language", 所以就叫它"cutest"好了，希望不要有人把首碼"cu"和"cuda"聯繫起來。

接下來我把自己切換到用戶的角度，說說我希望自己如何使用cutest。首先，測試的對象對我來說是一個個獨立的函數，我希望框架提供一種讓我定義單元測試函數的方法，定義完成之後我作為用戶的任務就完成了，至於如何讓框架知道有一個新的單元測試加入進來了，那不是我這個用戶應該關心的，我甚至不打算寫main函數，然後在main函數里告訴cutest去運行所有註冊進去的測試。我想要的只是定義單元測試，編譯鏈接，運行得到結果。總結起來，需求有以下3點：

用戶只要定義自己的單元測試函數即可。單元測試集的管理，運行，不需要用戶額外編寫代碼，即只要用戶定義完單元測試函數，編譯之後這個單元測試就自動被測試框架接管了，框架不需要提供額外的單元測試註冊介面。
在單元測試函數中支持斷言。類似gtest的EXCEPT_EQ等巨集的功能。
不需要其他外部依賴。用戶只要有一個框架的頭文件和編譯好的庫文件就可以直接使用。

在說明實現原理之前，我先劇透一下最終的用戶是如何使用cutest編寫單元測試的：

/*test1.c*/

/*include cutest header file*/
#include "cutest.h"

/*define a new test suit with the name 'test_suit1'*/
CUTEST_SUIT(test_suit1)

/*define first test case in test_suit1*/
CUTEST_CASE(test_suit1, test1) {
    int a = 10;
    int b = 10;
    CUT_EXPECT_EQ(a, b);
}

/*define the second test case in test_suit1*/
CUTEST_CASE(test_suit1, test2) {
    int a = 10;
    int b = 20;
    CUT_EXPECT_GT(a, b);
}

編譯這個test1.c文件，然後在shell中運行就可以得到結果了：

$ ./test1
 cutest summary:
         [test_suit1] suit result: 1/2
         [test_suit1::test2] case result: Fail
         [test_suit1::test1] case result: Pass

用戶的的單元測試可以放在多個文件中，但是定義單元測試函數的步驟是不變的，用戶的所有測試都會在運行結束之後得到一個彙總的統計信息。可以看到，cutest使用起來還是很簡單方便的。

如何實現

聊完了用戶的想法，需要考慮如何實現了。

基本數據結構

在cutest中我定義了兩種重要的數據結構：

test_case:

最基本的單元測試。對應用戶實現的單元測試函數，test_case中還記錄了測試的名字，測試的最終運行結果。
test_suit:

單元測試集合。用於管理一組test_case，理論上應該把一組相關性較大的test_case放在同一個集合中。測試框架中可以同時存在多個test_suit。

為了管理用戶定義的多個單元測試, 我採用了鏈表數據結構。test_case本身是一個鏈表，通過當前的test_case可以找到下一個test_case；每個test_suit中包含一個test_case的鏈表，這個鏈表就是這個test_suit管理的全部單元測試，test_suit自身也是一個鏈表，通過這個鏈表指針可以找到下一個test_suit。兩個結構體的定義如下：

typedef struct test_case {
    char *test_name;
    test_func test_func;
    struct test_case *test_case_next;
    int test_result;
} test_case;

typedef struct test_suit {
    char *test_suit_name;
    test_case *test_case_list;
    int test_case_total;
    int test_case_passed;
    struct test_suit *test_suit_next;
} test_suit;

在test_case中除了維護鏈表，還記錄了測試名字和結果；同理，test_suit額外記錄了當前測試集合的名字，包含的全部單元測試個數，以及測試通過的個數，這些信息將用於最後的測試結果統計。

如何實現單元測試的自動註冊

為了管理全部的單元測試，還需要一個test_suit的頭節點，當用戶代碼定義了新的test_suit的時候，會自動的加入到這個頭節點上；同時，當用戶在新的test_suit上定義新的test_case時，需要能夠自動加入到該test_suit的test_case鏈表上。下麵的一個關鍵問題就是如何在用戶定義test_suit或者test_case的同時自動註冊到cutest框架中。這裡用到的方式是通過編譯器給一個函數添加"construtor"屬性，這樣在程式運行時，具有"constructor"屬性的函數會由c庫調用，編程者可以定義多個"constructor"函數，這些函數會在main函數開始之前被調用，利用這個特性我們可以在“constructor”函數中實現test_suit以及test_case的註冊，這樣就實現了讓cutest框架管理這些用戶數據。下麵以CUTEST_SUIT巨集的實現為例，說明test_suit的註冊是如何完成的：

/* CUTEST_SUIT巨集的功能由兩個輔助巨集實現.
 * __DEFINE_CUTEST_SUIT定義個一個test_suit變數，並對其成員進行了初始化;
 * __REGISTER_CUTEST_SUIT定義了一個"constructor"函數, 在該函數中, 上一步定義的test_suit被添加到了test_suit的鏈表中;
 */
#define CUTEST_SUIT(suit_name)                                                 \
    __DEFINE_CUTEST_SUIT(suit_name)                                            \
    __REGISTER_CUTEST_SUIT(suit_name)

/*定義test_suit變數*/
#define __DEFINE_CUTEST_SUIT(suit_name)                                        \
    test_suit __CUTEST_SUIT_NAME(suit_name) = __CUTEST_INIT_SUIT(suit_name);

/*定義"constructor函數, 完成test_suit的註冊"*/
#define __REGISTER_CUTEST_SUIT(suit_name)                                      \
    void __attribute__((constructor))                                          \
    __cutest_register_test_suit_##suit_name() {                                \
        __CUTEST_INSERT_TEST_SUIT(suit_name);                                  \
    }

上述巨集的實現用到的test_suit變數名以及"constructor"函數名是根據用戶傳遞進來的巨集參數拼接而成，只要保證用戶的參數正確就不會出現變數重覆定義的問題。每次用戶定義一個新的test_suit就會自動定義出一個不同名字的"constructor"函數，而這些函數運行時的調用順序是有c庫決定的，但不管調用順序如何只要不會併發調用，對cutest來說就是無關緊要的，因為調用順序隻影響鏈表節點的順序，但cutest並未承諾保證單元測試的執行順序。

對於test_case的註冊和管理採用了相同的技術實現，這裡不再重覆。

如何獲取測試結果

對於每個單元測試函數，其函數簽名實際上是void (*) (void), 在註冊test_case的時候，由巨集定義的"constructor"函數預設會將test_case的test_result置為CUTEST_PASS，即預設情況下單元測試的狀態是通過。如果用戶需要把當前的測試標記為FAIL，可以在單元測試函數中使用CUT_FAIL巨集。在代碼中可以這樣實現：

CUTEST_SUIT(test_suit2)

CUTEST_CASE(test_suit2, test2) {
    CUT_EXPECT_EQ(10, 10);
    CUT_FAIL();
}

當CUT_FAIL巨集會設置當前測試的狀態，並且讓單元測試函數return。除了CUT_FAIL，cutest還提供了其他用於比較的巨集，比如CUT_EXPECT_EQ, CUT_EXPECT_NE, CUT_EXPECT_LT等，這樣的設計延續了其他測試框架的使用方式，用戶的使用成本更低。cutest提供的斷言類巨集最終的實現都是基於一個巨集CUT_EXPECT_TRUE，這個巨集的實現如下：

#define CUT_EXPECT_TRUE(c)                                                     \
    do {                                                                       \
        if (!(c)) {                                                            \
            __cutest_current_test_case__->test_result = CUTEST_FAIL;           \
            __cutest_current_test_suit__->test_case_passed -= 1;               \
            return;                                                            \
        }                                                                      \
    } while (0)

如果條件為假，該巨集會把當前test_case的結果設為FAIL，把對應test_suit中PASS狀態的測試數量減1，最後return。其他巨集的實現只需要構造合適的條件c，傳遞給CUT_EXPECT_TRUE即可。

如何做到可以不寫main函數

這是因為在cutest庫中已經定義了一個main函數，在main函數中代替用戶完成了運行全部單元測試的工作。

int main(int argc, char **argv) {
    cutest_run_all();
    return 0;
}

當用戶程式和libcutest.so進行鏈接之後，生成的可執行程式就有了main函數，當然用戶也可以自己重新定義一個main函數，去執行更複雜的功能，如果沒有其他需求就可以不必定義main函數。

寫在最後

至此，cutest實現過程中用到的一些技術細節都已經介紹完畢。對於我目前的使用，其功能已經足夠了，但還是有些需要完善的地方，比如：

在多線程環境下是否能夠正常使用？當用戶自己定義main函數時，使用多個線程調用cutest_run_all函數會存在哪些問題？
能否做到跨平臺？給函數添加"constructor"屬性，不知道在WIndows上是否可行，不過這一點目前不是重點。
目前的CUT_EXPECT_XX巨集，當條件不成立時處理的邏輯是標記測試為FAIL並從單元測試函數return。這樣的邏輯對於用戶需要在return之前釋放一些資源的情況是不適用的，這個問題需要後續解決。

最後，再放一個代碼傳送門，期待各位提出的建議。後續會發佈系列文章"linux環境編程"，歡迎持續關註。

本文來自博客園，作者：kfggww，轉載請註明原文鏈接：https://www.cnblogs.com/kfggww/p/17064038.html