4.2JUnit框架
單元測試
編寫單元測試的目的是為了提高身為一個程序員的生產性能。至于讓質保部門開心，那只是附帶效果而以。單元測試是高度本地化的東西，每個test class只對單一package運作。它能夠測試其他packages的接口，除此之外它將假設其他package一切正常。
功能測試
用來保證軟件能夠正常運作。他們只負責向客戶提供質量保證，并不關心程序員的生產力。它們應該由一個喜歡尋找臭蟲的個別團隊來開發。這個團隊應該使用重量級工具和技術來幫助自己開發良好的功能測試。
一般而言，功能測試盡可能把整個系統當作一個黑箱。面對一個GUI待測系統，它們通過GUI來操作那個系統。而對文件更新程序或數據庫更新程序，功能測試只觀察待定輸入所導致的數據變化。
一旦功能測試者或最終用戶找到軟件中的一個bug，要除掉它至少需要做兩件事。當然你必須修改代碼，才得以排除錯誤，但你還應該添加一個單元測試，讓它揭發這只臭蟲。
4.3添加更多的測試
觀察class該做的所有事情，然后針對任何一項功能的任何一種可能失敗的情況，進行測試。這不同于某些程序員提倡的“測試所有public函數”。記住，測試應該是一種風險驅動行為，測試的目的是希望找出現在或未來可能出現的錯誤。所以我不會去測試那些僅僅讀或寫一個值域的訪問函數，因為它們太簡單了，不大可能出錯。這一點很重要，因為你如果撰寫過多測試，結果往往測試量反而不夠。測試的要訣是：測試你最擔心出錯的部分，這樣你就能從測試工作中得到最大收益。
考慮可能出錯的邊界條件，把測試火力集中在那兒。
尋找邊界條件，也包括尋找特殊的、可能導致測試失敗的情況。對于文件相關測試，空文件是個不錯的邊界條件。當事情被大家認為應該會出錯時，別忘了檢查彼時是否有異常如預期般的被拋出。
不要因為“測試無法捕捉所有臭蟲”，就不撰寫測試代碼，因為測試的確可以捕捉大多數臭蟲。
對象技術有個微妙處：繼承和多態會讓測試變得比較困難，因為將有許多組合需要測試。如果你有三個彼此合作的abstract class有三個subclass，那么你總共有九個可供選擇的classes，和27種組合。我并不總是試著測試所有可能組合，但我會盡量測試每一個classes，這可以大大減少各種組合所造成的風險。如果這些classes之間彼此有合理的獨立性，我很可能不會嘗試所有組合。是的，我總有可能遺漏些什么，但我覺得“花合理時間抓出大多數臭蟲”要好過“窮盡一生抓出所有臭蟲”。
測試代碼和產品代碼之間有個區別：你可以放心的拷貝、編輯測試代碼。