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
  • 隨著Aspire發佈preview5的發佈,Microsoft.Extensions.ServiceDiscovery隨之更新, 服務註冊發現這個屬於老掉牙的話題解決什麼問題就不贅述了,這裡主要講講Microsoft.Extensions.ServiceDiscovery(preview5)以及如何 ...
  • 概述:通過使用`SemaphoreSlim`,可以簡單而有效地限制非同步HTTP請求的併發量,確保在任何給定時間內不超過20個網頁同時下載。`ParallelOptions`不適用於非同步操作,但可考慮使用`Parallel.ForEach`,儘管在非同步場景中謹慎使用。 對於併發非同步 I/O 操作的數量 ...
  • 1.Linux上安裝Docken 伺服器系統版本以及內核版本:cat /etc/redhat-release 查看伺服器內核版本:uname -r 安裝依賴包:yum install -y yum-utils device-mapper-persistent-data lvm2 設置阿裡雲鏡像源:y ...
  • 概述:WPF界面綁定和渲染大量數據可能導致性能問題。通過啟用UI虛擬化、非同步載入和數據分頁,可以有效提高界面響應性能。以下是簡單示例演示這些優化方法。 在WPF中,當你嘗試綁定和渲染大量的數據項時,性能問題可能出現。以下是一些可能導致性能慢的原因以及優化方法: UI 虛擬化: WPF提供了虛擬化技術 ...
  • 引言 上一章節介紹了 TDD 的三大法則,今天我們講一下在單元測試中模擬對象的使用。 Fake Fake - Fake 是一個通用術語,可用於描述 stub或 mock 對象。 它是 stub 還是 mock 取決於使用它的上下文。 也就是說,Fake 可以是 stub 或 mock Mock - ...
  • 為.net6在CentOS7上面做準備,先在vmware虛擬機安裝CentOS 7.9 新建CentOS764位的系統 因為CentOS8不更新了,所以安裝7;簡單就一筆帶過了 選擇下載好的操作系統的iso文件,下載地址https://mirrors.aliyun.com/centos/7.9.20 ...
  • 經過前面幾篇的學習,我們瞭解到指令的大概分類,如:參數載入指令,該載入指令以 Ld 開頭,將參數載入到棧中,以便於後續執行操作命令。參數存儲指令,其指令以 St 開頭,將棧中的數據,存儲到指定的變數中,以方便後續使用。創建實例指令,其指令以 New 開頭,用於在運行時動態生成並初始化對象。方法調用指... ...
  • LiteDB 是一個輕量級的嵌入式 NoSQL 資料庫,其設計理念與 MongoDB 類似,但它是完全使用 C# 開發的,因此與 C# 應用程式的集成非常順暢。與 SQLite 相比,LiteDB 提供了 NoSQL(即鍵值對)的數據存儲方式,並且是一個開源且免費的項目。它適用於桌面、移動以及 We ...
  • 1 開源解析和拆分文檔 第三方的工具去對文件解析拆分,去將我們的文件內容給提取出來,並將我們的文檔內容去拆分成一個小的chunk。常見的PDF word mark down, JSON、HTML。都可以有很好的一些模塊去把這些文件去進行一個東西去提取。 優勢 支持豐富的文檔類型 每種文檔多樣化選擇 ...
  • OOM是什麼?英文全稱為 OutOfMemoryError(記憶體溢出錯誤)。當程式發生OOM時,如何去定位導致異常的代碼還是挺麻煩的。 要檢查OOM發生的原因,首先需要瞭解各種OOM情況下會報的異常信息。這樣能縮小排查範圍,再結合異常堆棧、heapDump文件、JVM分析工具和業務代碼來判斷具體是哪 ...