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

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

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

隔離還是不隔離？

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

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

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

3個簡單的Mock原因

這是一些更明顯的情況：

1.合作者尚未實施或仍在開發中

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

2.硬件獨立性

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

3.故障注入

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

4個不那么直率的Mock原因

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

1.單元測試不可重復

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

2.測試環境難以初始化

初始化測試環境可能非常復雜。模擬真實的環境，以便他們為測試的代碼提供可靠的輸入，即使不是不可能，也是一項艱巨的任務。 

組件通常是相互關聯的，當嘗試初始化一個特定的模塊時，我們可能最終會初始化系統的一半。用偽造的實現代替真正的協作者可以降低測試環境初始化的復雜性。

3.測試狀態難以確定

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

用mock代替真正的環境通常可以解決問題，并且我們可以使用各種訪問方法來擴展偽造的實現以確定測試結果。

4.測試很慢

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

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

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

1. 真正的環境是我測試穩定性的風險源嗎？
2. 初始化真正的環境難嗎？
3. 測試后是否可以驗證環境的狀態，以決定測試狀態？
4. 環境需要多長時間作出回應？

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

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