1、上路
1.1 什么是單元測試？
單元測試是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常情況下，一個單元測試（用例）用于判斷某個特定條件（或場景）下特定函數的行為。
例如，我們要編寫一個類，它要實現有序的List功能，當向其添加一個元素時，程序應該能夠按照它的大小將其插到合適的位置。這是我們編寫一個測試用例，將一個很大的值放入這個List中，然后確認該值出現在List的尾部。
簡單地說，執行單元測試是為了驗證某段代碼的行為是否與開發者所期望的一致。
單元測試是必要的嗎？
單元測試是由開發者編寫和執行的，針對的也只是那些很小規模的代碼，那么對于客戶或最終用戶來說，它們影響大嗎？它們是必要的嗎？
其實，我們在進行單元測試時，我們所關心的規模很小的、獨立的代碼片段。我們的哲學是首先對所有單獨部分的行為建立起信心（確信它們與期望一致），然后再安心的組裝和測試整個系統。畢竟，如果蓋房所用的磚瓦都沒法保證質量，我們對房子還能期望什么呢？如果不先對磚瓦進行檢查、驗證，那么盲目的進行建筑豈不是極大的浪費？
另一方面，單元測試只是各種測試中的第一步，在此之后，我們還需要其它形式的測試，比如集成測試、系統測試等，這個就視需要而定了。
1.2 為什么要使用單元測試？
“單元測試讓生活更輕松�！�
這聽起來像是某句廣告詞，它究竟效果如何呢？
讓我們回到現實，假定我們正在開發一個網站程序。首先我們會將整個程序設計為三層：數據訪問層、業務邏輯層和表現層。首先是編寫數據訪問層，如何測試它是否正確呢？如果沒有進行單元測試，那么就得等到業務邏輯層和表現層開發完畢后才能打開頁面進行測試。而這中間，業務邏輯層要調用數據訪問層，表現層要調用業務邏輯層的代碼。如果通過頁面發現某個功能沒有通過，我們就得進行調試，調試時要一步一步地跟蹤代碼，好不容易找到bug所在了，原來是數據訪問的一個方法里出了問題，把該方法改好了，編譯不通過！看來還得修改另外兩層的代碼，好，把代碼都改好了，再次打開頁面進行測試，糟糕還是沒通過。上面的過程再來一次。。。
上面這種方式的缺點可以總結為：
錯誤難以定位：每次要打開頁面、輸入值、調試，單元測試可能也需要這些過程，但其工作量則會小很多。
執行時間長：較之單元測試，上面的方式顯然耗時得多。
代碼覆蓋：可以理解的是，涉及的代碼層次越多，就越是難以確定被測代碼和測試值之間的關系。我們要覆蓋到所有的數據訪問層的代碼，就要花費很大的精力。
在應用了（好的）單元測試后，一切都將變得不同了。我們可以快速定位錯誤，執行的時間也要短得多，代碼覆蓋也更容易進行。
如果一開始就對數據訪問層和業務邏輯層進行了良好的單元測試，那么接下來表現層的開發就順利得多了，我們相信前面的代碼已經相當不錯了，可以開心地編寫后面的代碼。一旦出了問題，我們也很容易定位和修改。
所以說，單元測試讓開發人員對自己的代碼充滿信心，這項看似簡單的技術可以讓代碼變得更加完美，從而讓我們的生活更輕松。
1.3 它能給我帶來什么？
引入單元測試是簡單的，它本身是充滿樂趣的，但我們不會將它交給客戶和最終用戶。我們得考慮一下，單元測試的目的是什么。首先的一點是，使用單元測試是為了讓我們的工作更為輕松。
當然了，可執行的文檔具有自我驗證正確與否的優點，在首次編寫后就不需很大的工作量了。不像普通意義上的文檔，它不會出現與代碼不一致的情況（除非你不再執行測試或者讓它們一直失敗下去）。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/