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

在我們的例子中，目標(biāo)硬件是Zynq-7000 SoC的ZedBoard。之所以挑選Zedboard是因?yàn)樗写罅繐碥O和很多簡便可用的參考設(shè)計(jì)。不過其不足是，一板難求！——由于需求量大，這塊開發(fā)板的運(yùn)送時(shí)間超過2個(gè)月。不過目標(biāo)硬件送達(dá)延遲對嵌入式開發(fā)者來說是個(gè)普遍問題。沒有目標(biāo)硬件，嵌入式開發(fā)者通常只有兩種選擇：

等待，或…

在沒有硬件的情況下開發(fā)并測試高質(zhì)量應(yīng)用

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

我們的應(yīng)用是一個(gè)視頻演示平臺。在這個(gè)平臺上，Zynq SoC中ARM Cortex-A9 MPCore CPU上運(yùn)行的軟件創(chuàng)建一系列視頻幀，將它們通過由Xilinx IP核組建的硬件流水線傳輸?shù)?a target="_blank">HDMI視頻輸出。我們的目的就是通過模擬設(shè)備驅(qū)動(dòng)來寫入和測試整個(gè)應(yīng)用程序。然后，當(dāng)收到ZedBoard后，我們就可以用真正的設(shè)備驅(qū)動(dòng)來重新部署我們的應(yīng)用了。

模擬設(shè)備驅(qū)動(dòng)功能

我們選擇一個(gè)對我們單元測試很好的粒度（granularity）水平，因此我們能夠從一系列很小的步驟開始建立和測試我們的應(yīng)用程序， 每一步測試完畢后再進(jìn)行下一步。例如，軟件功能是用xiic_l.中的Xiic_DynInit()函數(shù)對目標(biāo)硬件I2C 控制器基地址進(jìn)行適當(dāng)?shù)某跏蓟?/p>

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

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

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

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

這個(gè)難題的最后一塊就是調(diào)用GoolgeMock來填充Xiic_DynInit()函數(shù)的存根應(yīng)用 。如下所示：

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

測試你的第一個(gè)功能

為了用我們新的設(shè)備驅(qū)動(dòng)模擬器開始編寫測試，我們首先需要建立GoogleTest線束，這相對簡單，涉及新建測試單元實(shí)例，叫做licCtrl的類和xdriverMock的一個(gè)副本。如果你的測試單元是純粹的C函數(shù)而不是像我們這樣的C++類，當(dāng)然你就只要直接調(diào)用C函數(shù)，不必管該類實(shí)例了。

對單元測試來說，大多數(shù)有關(guān)GoogleMock的相互作用是通過EXPECT_CALL宏發(fā)生的。有了這個(gè)宏，我們能夠驗(yàn)證我們的應(yīng)用程序滿足所有期望的與設(shè)備驅(qū)動(dòng)的相互作用。通常的做法例如，我們的應(yīng)用程序通過叫做init()的licCtrl的一個(gè)成員函數(shù)來調(diào)用Xiic_DynInit()。確認(rèn)運(yùn)行的測試如下：

測試程序的第一行中，我們使用EXPECT_CALL來說明，當(dāng)測試期間輸入值等于HDMI I2C基地址時(shí)，XIic_DynInit()函數(shù)應(yīng)當(dāng)被調(diào)用一次。第二行是調(diào)用我們iicCtrl應(yīng)用代碼里的init()方法。如果init()方法無法用我們期望的地址調(diào)用Xiic_DynInit()函數(shù)，一個(gè)斷言將在該模擬中發(fā)生，并且測試以失敗告終。否則，測試通過。

這個(gè)測試的模式很通用，這也是我們選擇在這兒展示的原因。不過，你可以設(shè)置更為復(fù)雜的預(yù)期來測試，例如返回值，指針的值和參考變量等等。

這些是使用GoogleMock來模擬設(shè)備驅(qū)動(dòng)和模仿與真實(shí)硬件間的相互作用，運(yùn)行于Zynq-7000 SoC 的ARM Cortex-A9 MPCore CPU上的測試應(yīng)用程序的基本原理。然而這個(gè)例子只展示了GoogleMock模擬的一個(gè)設(shè)備驅(qū)動(dòng)函數(shù)，我們有超過75個(gè)函數(shù)以相同的方式被模擬，以便讓我們在應(yīng)用程序中運(yùn)行超過100種測試；全都不用目標(biāo)硬件。