也許單元測試最關鍵的元素是測試框架。在這篇博文中，我們將討論在嵌入式開發中C語言的各種選擇，并簡要分析利弊。

　　考慮因素

　　Test Runners

　　大多數嵌入式編程使用C，下面討論的所有框架都是針對C或C++的。這本身會帶來一些困難。許多單元測試框架利用了被稱為“自省”的語言特性。實際上，這是在運行時確定正在執行的程序的結構信息的能力。它對于向框架自我注冊的測試非常有用，并廣泛用于面向Ruby、Python和Java等語言的框架。

　　實際上，這意味著C中的測試框架需要程序員做更多的設置工作。大多數框架需要一個手動編寫的“runner”來調用測試套件，這可能會導致錯誤，例如忘記向runner添加特定的測試。有一些工具可以幫助自動化這個過程，但是它們不在嚴格的“測試框架”的范圍之內——它們本身更類似于完整的構建系統。

　　C++有一些允許自省的特性，所以測試該語言的套件能實現自動測試注冊。在大多數情況下，將完全用C編寫的項目編譯和測試為C++是可能的。這通常是一個好的解決方案，但是對于不習慣這種語言的嵌入式開發人員來說可能會不太舒服。

　　在硬件上運行

　　有一篇文章，討論了運行測試的最佳位置。它列出了三個不同的選項：通過模擬器的開發系統、本地工作站或系統硬件。通常，使用前兩個選項中的一個是有意義的，但在某些情況下(或不同的測試)，使用其他選項可能有意義。

　　話雖如此，測試框架的選擇將影響到是否可以執行這些操作。根據你平臺可用的模擬器類型，可能很難使用依賴于在操作系統下運行的工具(如check))。這肯定不會對裸金屬硬件本身起作用。另一方面，當測試失敗可能導致分段錯誤時，具有在單獨的地址空間中運行測試的功能是非常好的。

　　框架選項

　　Unity

　　這個測試框架很輕，非常便于攜帶。開發人員聲稱，它可以移植到任何架構上，從高性能的x86機器到8位微控制器，包括具有神秘功能的架構，如奇怪的整數寬度。它專門針對嵌入式開發。

　　它的缺點是缺乏高級功能，如地址空間隔離，或自動運行程序生成和測試集成。它與ThrowTheSwitch工具套件集成得很好，其中包括CMock、CException以及Ceedling。當一起使用時，Unity的簡單性的許多缺點被減輕了。

　　Check

　　check是另一個相對輕量級的C單元測試框架。與Unity不同，相反，它專注于安全和簡單易用。它出名的主要原因是它在一個隔離的地址空間中運行每個測試，這意味著可以捕獲無效的內存訪問。相比之下，使用Unity的測試會因為分段錯誤而徹底失敗。

　　它還有一些比Unity更方便的功能，包括參數化測試，可以方便地編寫應該在一系列不同值上驗證輸出的例程。它在設計時沒有考慮裸機嵌入式開發。

　　check也有缺點。首先，很明顯，是對操作系統的依賴，這意味著直接移植到嵌入式系統非常困難，并且在模擬器下交叉編譯運行時可能會有問題。

　　其次，生成子進程比簡單的函數調用要昂貴得多，所以當check必須運行許多測試時，它往往會停滯不前。

　　像任何其他純C框架一樣，測試運行程序必須手工編寫。

　　GoogleTest

　　GoogleTest是Google的單元測試框架。它是用C++編寫的，但是稍加調整就可以用來測試C應用程序。它支持使用Google Mock，這對于測試依賴于硬件的模塊是必要的。

　　GoogleTest確實支持在單獨的地址空間中運行測試，但默認情況下并不這樣做。這些測試被稱為“死亡測試”，它們主要用于捕捉預期的故障，而不是對意外segfaults等的保護。

　　這個測試框架的文件非常好，嵌入式開發人員值得一看。