linux環境編程(1): 實作一個單元測驗框架-有解無憂

寫在前面

在開發的程序中，大多數人都需要對代碼進行測驗，目前對于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

轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/542351.html

標籤：Linux

上一篇：推薦ssh工具

下一篇：AX9000安裝使用Docker