Junit內部解密之四： Junit單元測試最佳實踐

　　我們做使用Junit工具來做單頁測試或接口測試時，需要注意一些問題，包括我們的編碼規范，test規范，以及編寫測試代碼的策略，以下個人的總結。

　　1.為還沒有實現的測試代碼拋出一個異常。這就避免了該測試通過，而且會提醒你必須實現其代碼。

　　2.一次只測試一個對象。單元測試一個重要的方面就是細粒度，它獨立的檢查你創建的每個對象，這樣你就可以在問題發生的第一時間就把它們隔離起來。如果測試多于一個對象，那么你就無法預測到這些對象發生了改變時它們會如何相互影響的。

　　3.選擇有意義的測試方法名。你應當能通過閱讀方法名就可以理解要測試的是什么方法。一條好的規則就是一開始就遵守test_XX1_XX2的命名模式，其中XX1是待測方法名，XX2就是測試條件或目的。

　　4.在assert調用中解釋失敗原因。無論何時，只要你用到assertTrue,assertFalse,assertNull,assertNotNull方法，請記住要使用第一個參數是String類型的那個方法，這個參數讓你可以提供一個有意義的文本描述，在斷言失敗的時候，Junit TestRunner 會顯示這個描述，若不使用這個參數，那么當測試失敗時就比較難找出失敗原因了。

　　5.測試任何可能失敗的事物。測試主執行路徑很好，而且很需要做;但測試異常處理可能更重要。如果主執行路徑出錯，那么可能應用程序也無法工作。

　　6.讓測試改善代碼。編寫單元測試常常有助于你寫成更好的代碼。理由很簡單，testcase是你的代碼的用戶，只有在使用代碼的時候才能發現代碼的缺點，所以應當根據測試時發現的不便之處重構代碼，使其更易于使用。TDD就類似，通過先編寫測試，再從代碼用戶的角度來開發你的類。

　　7.讓異常測試易讀。把catch塊中的異常變量命名為expected，這樣就可以明確的告知讀代碼的人，這個異常是我們預期的，拋出異常才能讓測試通過，在catch塊中加入assertTrue(true)語句也進一步強調，這才是正確的執行路徑。

　　8.同一個包，分離的目錄。把所有測試類和待測類都放在同一個包中，但使用平行目錄結構，為了可以訪問保護型的方法，需要把測試和待測類放在同一個包中，為了簡化文件管理，并讓人清晰的分辨測試類和開發代碼類，所有需要把測試放在一個單獨的目錄中。當然我們也可以使用一個test的包，進行遺漏所有開發包。這樣也可以把test需要的resources文件也可也獨立起來。

　　9.存在三種單元測試：邏輯單元測試，集成單元測試，功能單元測試。邏輯單元測試主要是檢查代碼邏輯性，通常只是針對單個方法，一般可以通過mock objects 和stub 來控制特定的方法的邊界。集成單元測試主要是在真實環境下的一個組件相互交互的測試。功能單元測試目的是為了確認響應的結果是否正確，這種單元測試更多的依賴于外部環境。

　　10.考察單元測試的覆蓋率。一種方法就是數一下你的測試中用到了多少方法。使用Clover工具進行覆蓋率統計，記住100%的測試覆蓋并不能保證你的應用程序得到了100%的測試。

　　11.測試先行。在寫任何代碼之前，必須先寫一個失敗的測試。為啥是失敗的測試呢，因為不是失敗的測試，老是成功的測試，你就不會改進這些代碼來使其更加具有維護性。

原文轉自：http://www.anti-gravitydesign.com