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工具進行覆蓋率統計，記住的測試覆蓋并不能保證你的應用程序得到了的測試。
11.測試先行。在寫任何代碼之前，必須先寫一個失敗的測試。為啥是失敗的測試呢，因為不是失敗的測試，老是成功的測試，你不會改進這些代碼來使其更加具有維護性。
