Neil Johnson – 首席顧問 – XtremeEDA
Soheil Salehian – 助理研究員 – 卡爾加里大學

模擬（Mocking）是嵌入式系統開中用于單元測試和測試驅動的一種技術。模擬的好處在于通過刪除不相關的從屬代碼，它允許開發者很容易地隔離和單元測試其中一部分代碼。在嵌入式系統中，這些從屬代碼可能被當作由設備驅動和硬件運行的功能集合而存在。在這篇博客中，我們將討論關于模擬設備驅動和硬件以及使用GoogleTest和GoogleMock來測試應用程序代碼。

在我們的例子中，目標硬件是Zynq-7000 SoC的ZedBoard。之所以挑選Zedboard是因為它有大量擁躉和很多簡便可用的參考設計。不過其不足是，一板難求！--由于需求量大，這塊開發板的運送時間超過2個月。不過目標硬件送達延遲對嵌入式開發者來說是個普遍問題。沒有目標硬件，嵌入式開發者通常只有兩種選擇：

a) 等待，或…
b) 在沒有硬件的情況下開發并測試高質量應用

我們的選擇是不等待 :-)

我們的應用是一個視頻演示平臺。在這個平臺上，Zynq SoC中ARM Cortex-A9 MPCore CPU上運行的軟件創建一系列視頻幀，將它們通過由Xilinx IP核組建的硬件流水線傳輸到HDMI視頻輸出。我們的目的就是通過模擬設備驅動來寫入和測試整個應用程序。然后，當收到ZedBoard后，我們就可以用真正的設備驅動來重新部署我們的應用了。

模擬設備驅動功能
我們選擇一個對我們單元測試很好的粒度（granularity）水平，因此我們能夠從一系列很小的步驟開始建立和測試我們的應用程序， 每一步測試完畢后再進行下一步。例如，軟件功能是用xiic_l.中的Xiic_DynInit()函數對目標硬件I2C 控制器基地址進行適當的初始化。

為了模擬像Xiic_DynInit()這樣的設備驅動程序，我們的應用包含賽靈思設備驅動頭文件xiic_l.h，正如你通常做的一樣。然后我們新建我們自己的該函數實現的存根來代替從libxil.a中鏈接真正的設備驅動代碼。這存根始于空的實現體，由此我們可以流水清除Makefile然后build，確保編譯器和鏈接器都沒問題（大多數有經驗的開發者也許不會有這個習慣，但是這是個開始階段，我們覺得有幫助）。

下一步是在存根下插入真正的功能，我可以使用這些功能來模擬設備驅動的功能。這就是要用到GoogleMock。GoogleMock 是一個C++框架，我們用它來模擬C函數（實際上GoogleMock只是個C++框架，對C++不熟悉的開發者不必為此擔心。所有的事都會由單內襯（one-liner）的宏和函數完成，所以你會感到在沒C++知識下創建和使用模擬也很容易）。

我們選擇模擬GoogleMock中的一些設備驅動,叫做xdriverMock。在xdriverMock中，有我們感興趣的每個函數的聲明。例如 Xiic_DynInit(),我們使用MOCK_METHOD1，用來定義一個輸入變量的函數。（類似的，也有MOCK_METHOD2，MOCK_METHOD3之類的來聲明有任意個輸入變量的函數。）MOCK_METHOD宏定義了很多一般特性使得編寫單元測試和測試相互作用變得非常容易。更多好處還在后面。

作為我們 xdriverMock的一部分，我們也有叫做getXdriverMock()和destroyXdriverMock()的全局函數分別來實例化和析構這個mock對象。如果你熟悉C++，getXdriverMock()和destroyXdriverMock()函數很像是構造函數和析構函數；它們構造一個xdriverMock的實例用于測試，然后析構作為碎片收集。在具體實現的文件里這些方法看上去如下：

有了這個，我們就成功地用GoogleMock代替了真正設備驅動的功能。對單元測試來說，我們現在有了對設備驅動功能完整的控制，也擺脫了對硬件的依賴。記住我們的首要任務是驗證分配給 I2C控制器的基地址，現在我們可以開始編寫驗證應用程序正常工作的單元測試了。

測試你的第一個功能
為了用我們新的設備驅動模擬器開始編寫測試，我們首先需要建立GoogleTest線束，這相對簡單，涉及新建測試單元實例，叫做licCtrl的類和xdriverMock的一個副本。如果你的測試單元是純粹的C函數而不是像我們這樣的C++類，當然你就只要直接調用C函數，不必管該類實例了。