單元測試是一種細粒度的測試，已經成為很多公司正常開發流程的一部分，在要求提交**的同時提交單元測試**。最著名的單元測試框架是junit，xp方法學先驅kent beck與設計模式代表人物erich gamma作品，成為單元測試領域的事實標準。寸有所長尺有所短，單元測試作為一門工具方法，致力於解決某些問題，只有全面、客觀了解，才能在具體工作應用當中產生正面影響。單元測式是在隔離狀態下對某個模組進行測試，目的是檢驗其行為。一旦我們在受控的條件下對模組進行了徹底的測試，我們就能夠有信心的預期軟體整體情況。典型的單元測試，在某種人工環境下，呼叫被測試模組的方法，然後根據預期值，對返回結果進行檢驗。
按合約設計（dbc）用文件約定了軟體模組的權利與責任：做它宣告要做的事情，不多不少，用文件記載這樣的宣告，並進行較驗。單元測試是針對合約的測試。編寫的測試用例確保給定的單元遵守其合約：**是否符合合約，以及合約的定義是否與我們所認為的一樣。通過廣泛的測試用例和邊界條件，測試模組是否實現了它允諾的功能。
提供一些例子，說明怎麼樣使用的你的模組。也許有過同樣的經驗，當使用第三方元件不清楚其api是怎麼樣呼叫時，會去檢視其api文件，跳過其大段的說明，直接看其樣例，然後照樣例畫瓢。同樣單元測試具有樣例的功能。
為以後的重構，提供安全保障。在《重構：改善既有**設計》提到，在重構前，必須建立其測試保障體系，以確定重構是否有改其軟體行為。
降低其不確定性從而降低其風險。在開發中，有多長時間是在和**編緝器找交道，又有多長時間在和偵錯程式打交道？從表面上看，為每個單元編寫測試**增加了工作量，但是因為這些測試**不僅為你提供了保護網，可以幫你迅速定位錯誤，減小對偵錯程式的依賴。所以增加一些工作量，物有所值，而且現今的測試工具，如junit，只需寫很少的測試**。
關於測試的若干誤解
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...
單元測試（三） 建立多執行緒單元測試
junit本是不支援多執行緒的，乙個單元測試case主程序跑完，其他new出來的執行緒都會gg思密達。此篇mark乙份在junit中執行多執行緒的方法。net.sourceforge.groboutils groboutils core 5test slf4j public class device...