單元測試

　　單元測試(模塊測試)是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件(或者場景)下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認該值出現在list 的尾部?；蛘?，你可能會從字符串中刪除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。

　　單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

　　工廠在組裝一臺電視機之前，會對每個元件都進行測試，這，就是單元測試。

　　其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什么的，這，也是單元測試，老納把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高后期測試和維護成本，也降低了開發商的競爭力?？梢哉f，進行充分的單元測試，是提高軟件質量，降低開發成本的必由之路。

　　對于程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。

　　要進行充分的單元測試，應專門編寫測試代碼，并與產品代碼隔離。老納認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數(很簡單的除外)建立測試函數。首先就幾個概念談談老納的看法。

　　一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以老納的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。

　　有一種看法是，只測試類的接口(公有函數)，不測試其他函數，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯并最終排錯，因此，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對于C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫(inline函數)，所有在源文件編寫實現的函數都要進行測試(構造函數和析構函數除外)。

　　為什么要使用單元測試

　　我們編寫代碼時，一定會反復調試保證它能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會愿意交付給自己的老板。但代碼通過編譯，只是說明了它的語法正確;我們卻無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。

　　幸運，單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。有了單元測試，我們可以自信的交付自己的代碼，而沒有任何的后顧之憂。

　　什么時候測試?單元測試越早越好，早到什么程度?XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工作中，可以不必過分強調先什么后什么，重要的是高效和感覺舒適。從老納的經驗來看，先編寫產品函數的框架，然后編寫測試函數，針對產品函數的功能編寫測試用例，然后編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的隨便返回一個值，編譯通過后再編寫測試代碼，這時，函數名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以后需修改的可能性比較小。

　　由誰測試?單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。

　　關于樁代碼，老納認為，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產品函數或測試函數調用了一個未編寫的函數，可以編寫樁函數來代替該被調用的函數，樁代碼也用于實現測試隔離。采用由底向上的方式進行開發，底層的代碼先開發并先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量;測試上層函數時，也是對下層函數的間接測試;當下層函數修改時，通過回歸測試可以確認修改是否導致上層函數產生錯誤。

　　在一種傳統的結構化編程語言中，比如C，要進行測試的單元一般是函數或子過程。在象C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發人員可以選擇是在獨立的過程和函數，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言(4GL)的開發中，在這里基本單元被典型地劃分為一個菜單或顯示界面。

　　單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試必須是可重復的，無論是在軟件修改，或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟件系統的生命周期中進行維護。

　　經常與單元測試聯系起來的另外一些開發活動包括代碼走讀(Code review)，靜態分析(Static analysis)和動態分析(Dynamic analysis)。靜態分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數據，并不需要對代碼進行編譯和執行。動態分析就是通過觀察軟件運行時的動作，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。

　　一些流行的誤解

　　在明確了什么是單元測試以后，我們可以進行"反調論證"了。在下面的章節里，我們列出了一些反對單元測試的普遍的論點。然后用充分的理由來證明這些論點是不足取的。

　　它浪費了太多的時間

　　一旦編碼完成，開發人員總是會迫切希望進行軟件的集成工作，這樣他們就能夠看到實際的系統開始啟動工作了。 這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。

原文轉自：http://blog.csdn.net/xuyubotest/article/details/4681999