單元測試就是測試單獨的單元。在本文中，我們將進行7次模擬，包括一些有用的問題，以便您可以指導(dǎo)自己完成C和單元測試。

我們需要多少單元測試隔離？在為C和C++開發(fā)單元測試時，這是一個反復(fù)出現(xiàn)的重要問題，經(jīng)常被爭論。我在這里不是在談?wù)撆c開發(fā)者的隔離，而是坐在開放空間中坐在我們旁邊，敲打他耳機的音樂節(jié)奏（順便說一句，當(dāng)我們想創(chuàng)造出色的質(zhì)量代碼時，這也很重要）。我說的是將經(jīng)過測試的代碼與其周圍環(huán)境（即所謂的協(xié)作環(huán)境）隔離開來。

在繼續(xù)之前，讓我先澄清一件事：在討論C和C++語言的存根和模擬時，由于語言層在復(fù)雜性，功能和期望方面的差異，通常在C和C++之間劃清界限。關(guān)于典型的模擬框架，使用Parasoft C/C++test時，情況略有不同，因為兩種語言都可以使用大多數(shù)框架功能。因此，在討論該主題時，我將給出一個C或C++單元測試示例，并且除非我專門將某項標(biāo)記為僅受C或C++支持，否則您應(yīng)始終假定這兩種語言均提供了特定功能。

隔離還是不隔離？

一方面，常識要求除非有充分的理由，否則我們不應(yīng)該孤立。最后，測試真正的協(xié)作者只會增加我們對代碼庫的滲透。為什么我們要放棄一些額外的代碼覆蓋范圍以及發(fā)現(xiàn)錯誤的可能性？好吧，看來有一些很好的理由——我們將很快進行討論。

另一方面，一個正統(tǒng)的單元測試人員會認為單元測試是對孤立的單元進行測試，并且應(yīng)該保持原樣。與真正的合作者進行測試是集成階段的領(lǐng)域。一個眾所周知的事實是，通過將真正的環(huán)境納入測試范圍，我們可以使測試噪音更大。依賴真實環(huán)境的測試不僅會對被測代碼中的更改做出反應(yīng)，而且還會對相關(guān)組件中的更改做出反應(yīng)。嘈雜的測試使維護過程更加昂貴，并且會分散注意力。從長遠來看，這種分散注意力通常成為放棄單元測試實踐的主要原因。

那么隔離測試代碼的策略是什么？鑒于上述情況，很難制定一個好的規(guī)則來確定需要mock哪些環(huán)境以提供對測試代碼的適當(dāng)隔離。從測試效率和有效性的角度來看，“盡可能地隔離”和“盡可能避免單元測試隔離”這兩種方法各有利弊。

3個簡單的Mock原因

這是一些更明顯的情況：

1.合作者尚未實施或仍在開發(fā)中

這很簡單。我們別無選擇，我們需要一個mock實現(xiàn)。下圖說明了這種典型的單元測試環(huán)境（SUT——被測系統(tǒng)，DOC——依賴組件/環(huán)境）：

2.硬件獨立性

對于編寫桌面應(yīng)用程序的開發(fā)人員來說，這類問題似乎遙不可及，但對于嵌入式開發(fā)人員而言，單元測試的硬件獨立性是一個重要方面，無需硬件即可實現(xiàn)高水平的測試自動化和執(zhí)行。一個很好的例子是被測單元與GPS硬件交互，期望提供一定的定位坐標(biāo)序列來計算速度。盡管我們建議您多做些運動，這是一個好主意，但我無法想象測試人員會在設(shè)備上跑來跑去以模擬運動，只是為了生成所需的測試輸入，而無論何時需要進行單元測試。為此，該示例說明了如果在開發(fā)過程中無法實現(xiàn)硬件獨立性，則設(shè)備的開發(fā)生命周期將進行GPS測試多晚。

3.故障注入

故意注入錯誤是測試中的常見情況。例如，這可用于測試內(nèi)存分配失敗，或查看硬件組件是否失敗。一些開發(fā)人員試圖在測試初始化階段激發(fā)真正的環(huán)境，以便當(dāng)從被測試的代碼中調(diào)用時，它會以錯誤響應(yīng)。對我來說，這不切實際，通常太麻煩了。通常，更好的選擇是測試特定的、仿造的實現(xiàn)來模擬故障。

4個不那么直率的Mock原因

除了這些明顯總是需要模擬的環(huán)境的明顯情況之外，還有其他一些更微妙的情況，仿造的環(huán)境是一個不錯的選擇。如果我們的測試過程遇到下面列出的任何問題，則表明需要更好地隔離測試的代碼。

1.單元測試不可重復(fù)

難以實現(xiàn)依賴于易失性的穩(wěn)定測試。在這種情況下通常會發(fā)生的情況是，我們在不更改測試代碼或測試代碼的情況下收到了不同的測試結(jié)果。瞬態(tài)可能是依賴系統(tǒng)調(diào)用或無法從測試內(nèi)部控制的外部信號的影響。一個典型的例子是系統(tǒng)時鐘——如果測試場景需要在特定的時間點做出反應(yīng)，那么如果沒有能夠完全控制對測試代碼的間接輸入有完全控制權(quán)的模擬協(xié)作者，則很難實現(xiàn)自動化。

2.測試環(huán)境難以初始化

初始化測試環(huán)境可能非常復(fù)雜。模擬真實的環(huán)境，以便他們?yōu)闇y試的代碼提供可靠的輸入，即使不是不可能，也是一項艱巨的任務(wù)。 

組件通常是相互關(guān)聯(lián)的，當(dāng)嘗試初始化一個特定的模塊時，我們可能最終會初始化系統(tǒng)的一半。用偽造的實現(xiàn)代替真正的協(xié)作者可以降低測試環(huán)境初始化的復(fù)雜性。

3.測試狀態(tài)難以確定

在許多情況下，確定測試結(jié)論需要在測試執(zhí)行后檢查協(xié)作者的狀態(tài)。使用真正的環(huán)境，通常是不可能的，因為在真正的協(xié)作者界面中沒有合適的訪問方法來查詢測試后的狀態(tài)。

用mock代替真正的環(huán)境通?？梢越鉀Q問題，并且我們可以使用各種訪問方法來擴展偽造的實現(xiàn)以確定測試結(jié)果。

4.測試很慢

在某些情況下，真實環(huán)境的響應(yīng)可能會花費大量時間。當(dāng)延遲變得不可接受以及何時需要隔離時，并不總是很清楚。測試運行中2分鐘的延遲是否可以接受？通常希望能夠盡快運行測試套件（也許在每次代碼更改之后）。與實際環(huán)境的交互導(dǎo)致的大量延遲會使測試套件變得太慢而無法實用。這些真正的環(huán)境可能會更快地提高幾個數(shù)量級，并使測試執(zhí)行時間達到可接受的水平。

有用的問題，以確定是否要mock

因此，在編寫新的C或C++單元測試并決定使用原始環(huán)境或模擬實現(xiàn)時，請考慮以下四個問題：

1. 真正的環(huán)境是我測試穩(wěn)定性的風(fēng)險源嗎？
2. 初始化真正的環(huán)境難嗎？
3. 測試后是否可以驗證環(huán)境的狀態(tài)，以決定測試狀態(tài)？
4. 環(huán)境需要多長時間作出回應(yīng)？

如果我們對環(huán)境的了解足夠多，可以回答所有這些問題，那么這是一個簡單的選擇。如果沒有，那么我建議您從真正的環(huán)境開始，然后嘗試回答這四個問題。實際上，這是大多數(shù)測試驅(qū)動開發(fā)（TDD）從業(yè)人員在日常工作中應(yīng)用的方法。這意味著您需要適當(dāng)注意測試用例并仔細檢查它們，直到它們變得穩(wěn)定為止。

大多數(shù)情況下，單元測試的隔離由于要測試的單元的依賴性而變得復(fù)雜。在某些情況下，顯然需要模擬從屬組件，但也需要更微妙的情況。在某些情況下，這不是很明確的方法，它取決于測試環(huán)境中依賴項所具有的風(fēng)險和不確定性。