C++單元測試本身是一個標準，各種實現(xiàn)之間有區(qū)別，對標準的理解、執(zhí)行程度也不同。而C#、Java語言是由商業(yè)公司掌握的，在這方面很少有問題，但是看完了本篇文章你會有許多意想不到的東西啊。

 一、 單元測試能幫助客戶更準更全面地找到錯誤，顯著提高軟件質(zhì)量
上圖顯示了一個包含許多對象的應用程序的測試模型，大橢圓表示應用程序，小橢圓表示對象，箭
頭表示用戶輸入，紅星表示潛在的錯誤。

在集成測試中為了發(fā)現(xiàn)錯誤，我們希望通過不斷修改輸入，引發(fā)對象間的相互作用使得某對象引發(fā) 潛在的錯誤，但這無疑是有難度的。由于其難度，開發(fā)人員只能依賴應用軟件的運行失敗來發(fā)現(xiàn)錯誤， 這樣不僅很難找到錯誤發(fā)生的準確位置，而且實際上還有大量的類沒有得到測試。

C++單元測試提供了一種更有效的發(fā)現(xiàn)錯誤的方法，它將應用程序中的最小單元分離開，使得測試更接近錯誤，只要簡單地對每個最小單元進行獨立測試，就很容易地使全面準確地找到所有的程序錯誤成 為可能。

單元測試能夠在改善軟件質(zhì)量的同時大量削減開發(fā)時間和成本
由于在較高的層次上修改一個類可能會改變多個程序部件的設計和功能性，因此越遲發(fā)現(xiàn)問題，通
◆常就要修改越多的代碼。當修改的代碼量增加時，其他兩個因素也會隨之增加：
◆修改每一個錯誤所需的時間和費用  在代碼中引入新的錯誤的機會

 一次又一次的研究證明，隨著問題被檢測出來的時間的推遲，發(fā)現(xiàn)軟件錯誤所需的時間和成本會驚 人地增加。C++單元測試由于能夠更容易地找到錯誤，就會減少發(fā)現(xiàn)它們的時間和資源。 其次，由于你每完一個類，就能發(fā)現(xiàn)和改正其中的錯誤，你就不需要在以后花費大量時間重新了解和摸索。

最后，最重要的理由是由于類的相互作用和關聯(lián)性，在單元級修改一個類只會影響到原始的類，避 免了各個單元間的相互作用引發(fā)新的錯誤。因此單元測試能保證大大削減開發(fā)的時間和成本。#t#

基于上述信息，單元測試看上去就象一劑萬能藥 如果是這樣的話，為什么每一個 C/C++開發(fā)人員 不馬上對每一個類進行單元測試？就目前可以使用的技術來說，對 C/C++的單元測試是一件困難、煩瑣 和耗時的事情，沒有很好的工具來自動化這一過程，使得許多 C/C++開發(fā)人員望而生畏。

 執(zhí)行C++單元測試的第一步是是目標類變得可測。這需要兩個工作：
◆設計一個運行目標類的測試驅(qū)動程序
◆設計樁函數(shù)，它們?yōu)楸粶y類所引用的任何外部資源返回值 建立一個測試驅(qū)動，需要建立一個新的類，除了C++單元測試原始類以外它不能用于任何其它目的。測試驅(qū) 動應該具有下列特性：
◆一個指定設置和清除的標準方式
◆一個選擇個別測試和所有有效測試的方法
◆一個分析輸出的預期（或非預期）結(jié)果的機制
◆一個標準的錯誤報告形式

為了充分而正確地測試類，你需要設計一個能夠完全檢查被測類的測試驅(qū)動；若干次修改和重寫這 樣一個測試驅(qū)動是免不了的。一旦建立了測試驅(qū)動，你必須仔細檢查它不能包含任何錯誤。C++單元測試驅(qū)動中 的一個錯誤會破壞這個測試，但是你無法單獨測試一個類，你也不能測試測試驅(qū)動本身。

如果你的類引用任何還沒有準備好或不可訪問的外部資源（如外部文件、數(shù)據(jù)庫和 CORBA 對象等），你必須建立相應的樁函數(shù)，它們的返回值類似于這些實際的外部資源應該返回的。

當建立這些樁函數(shù)時，你需要選擇樁函數(shù)的返回值，它們將影響程序的執(zhí)行路徑：
◆為了測試類的功能性必須執(zhí)行任何的路徑
◆足夠的路徑能夠提供徹底的測試覆蓋性