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

来源:https://www.cnblogs.com/kfggww/archive/2023/01/21/17064038.html
-Advertisement-
Play Games

寫在前面 在開發的過程中,大多數人都需要對代碼進行測試。目前對於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點:

  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環境編程",歡迎持續關註。

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


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
一周排行
    -Advertisement-
    Play Games
  • 一:背景 1. 講故事 年前遇到了好幾例托管堆被損壞的案例,有些運氣好一些,從被破壞的托管堆記憶體現場能觀測出大概是什麼問題,但更多的情況下是無法做出準確判斷的,原因就在於生成的dump是第二現場,借用之前文章的一張圖,大家可以理解一下。 為了幫助更多受此問題困擾的朋友,這篇來整理一下如何 快狠準 的 ...
  • 前言 .NET6 開始,.NET Croe API 項目取消了 Startup.cs 文件,在 Program.cs 文件的 Main 函數中完成服務的註冊和中間件管道的管理。但當我們項目引入更多包的時候,Program.cs 文件也會看起來很臃腫。 而且,我們不只會有一個後端項目,為了方便快速創建 ...
  • 目錄 背景 get 與 post 的區別 所有介面都用 post 請求? 背景 最近在逛知乎的時候發現一個有趣的問題:公司規定所有介面都用 post 請求,這是為什麼? 看到這個問題的時候其實我也挺有感觸的,因為我也曾經這樣問過我自己。在上上一家公司的時候接到一個項目是從零開始搭建一個微服務,當時就 ...
  • *以下內容為本人的學習筆記,如需要轉載,請聲明原文鏈接 微信公眾號「englyf」https://mp.weixin.qq.com/s/2GFLTstDC7w6u3fTJxflNA 本文大概 1685 個字,閱讀需花 6 分鐘內容不多, 但也花了一些精力如要交流, 歡迎關註我然後評論區留言 謝謝你的 ...
  • 在新版本的pandas中,上述代碼會引起警告,建議改成SQLAlchemy connectable(engine/connection),後續代碼將引入這種升級的連接方式。 ...
  • 幾乎所有的高級編程語言都有自己的垃圾回收機制,開發者不需要關註記憶體的申請與釋放,Python 也不例外。Python 官方團隊的文章 https://devguide.python.org/internals/garbage-collector 詳細介紹了 Python 中的垃圾回收演算法,本文是這篇 ...
  • 如果您想查找高於或低於平均值的數字,可以不必計算該平均值,就能查看更高或更低的值。通過Java應用程式,可以自動突出顯示這些數字。除了快速突出顯示高於或低於平均值的值外,您還可以查看高於或低於的值的個數。現在讓我們看看如何在 Java應用程式中實現此操作。 引入jar包 導入方法1: 手動引入。將  ...
  • 第一種方式:使用{} firstDict = {"name": "wang yuan wai ", "age" : 25} 說明:{}為創建一個空的字典對象 第二種方式:使用fromkeys()方法 second_dict = dict.fromkeys(("name", "age")) #valu ...
  • 在golang中可以使用a := b這種方式將b賦值給a,只有當b能進行深拷貝時a與b才不會互相影響,否則就需要進行更為複雜的深拷貝。 下麵就是Go賦值操作的一個說明: Go語言中所有賦值操作都是值傳遞,如果結構中不含指針,則直接賦值就是深度拷貝;如果結構中含有指針(包括自定義指針,以及切片,map ...
  • 本文結合京東監控埋點場景,對解決樣板代碼的技術選型方案進行分析,給出最終解決方案後,結合理論和實踐進一步展開。通過關註文中的技術分析過程和技術場景,讀者可收穫一種樣板代碼思想過程和解決思路,並對Java編譯器底層有初步瞭解。 ...