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

kfggww發表於2023-01-21
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點：

  1. 使用者只要定義自己的單元測試函式即可。單元測試集的管理，執行，不需要使用者額外編寫程式碼，即只要使用者定義完單元測試函式，編譯之後這個單元測試就自動被測試框架接管了，框架不需要提供額外的單元測試註冊介面。
  2. 在單元測試函式中支援斷言。類似gtest的EXCEPT_EQ等宏的功能。
  3. 不需要其他外部依賴。使用者只要有一個框架的標頭檔案和編譯好的庫檔案就可以直接使用。

在說明實現原理之前，我先劇透一下最終的使用者是如何使用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環境程式設計"，歡迎持續關注。

相關文章