Junit內(nèi)部解密之： Junit單元測試佳實(shí)踐
我們做使用Junit工具來做單頁測試或接口測試時(shí)，需要注意一些問題，包括我們的編碼規(guī)范，test規(guī)范，以及編寫測試代碼的策略，以下個(gè)人的總結(jié)。
1.為還沒有實(shí)現(xiàn)的測試代碼拋出一個(gè)異常。這避免了該測試通過，而且會提醒你必須實(shí)現(xiàn)其代碼。
2.一次只測試一個(gè)對象。單元測試一個(gè)重要的方面是細(xì)粒度，它獨(dú)立的檢查你創(chuàng)建的每個(gè)對象，這樣你可以在問題發(fā)生的第一時(shí)間把它們隔離起來。如果測試多于一個(gè)對象，那么你無法預(yù)測到這些對象發(fā)生了改變時(shí)它們會如何相互影響的。
3.選擇有意義的測試方法名。你應(yīng)當(dāng)能通過閱讀方法名可以理解要測試的是什么方法。一條好的規(guī)則是一開始遵守test_XX1_XX2的命名模式，其中XX1是待測方法名，XX2是測試條件或目的。
4.在assert調(diào)用中解釋失敗原因。無論何時(shí)，只要你用到assertTrue，assertFalse，assertNull，assertNotNull方法，請記住要使用第一個(gè)參數(shù)是String類型的那個(gè)方法，這個(gè)參數(shù)讓你可以提供一個(gè)有意義的文本描述，在斷言失敗的時(shí)候，Junit TestRunner 會顯示這個(gè)描述，若不使用這個(gè)參數(shù)，那么當(dāng)測試失敗時(shí)比較難找出失敗原因了。
5.測試任何可能失敗的事物。測試主執(zhí)行路徑很好，而且很需要做;但測試異常處理可能更重要。如果主執(zhí)行路徑出錯(cuò)，那么可能應(yīng)用程序也無法工作。
6.讓測試改善代碼。編寫單元測試常常有助于你寫成更好的代碼。理由很簡單，testcase是你的代碼的用戶，只有在使用代碼的時(shí)候才能發(fā)現(xiàn)代碼的缺點(diǎn)，所以應(yīng)當(dāng)根據(jù)測試時(shí)發(fā)現(xiàn)的不便之處重構(gòu)代碼，使其更易于使用。TDD類似，通過先編寫測試，再從代碼用戶的角度來開發(fā)你的類。
7.讓異常測試易讀。把catch塊中的異常變量命名為expected，這樣可以明確的告知讀代碼的人，這個(gè)異常是我們預(yù)期的，拋出異常才能讓測試通過，在catch塊中加入assertTrue(true)語句也進(jìn)一步強(qiáng)調(diào)，這才是正確的執(zhí)行路徑。
8.同一個(gè)包，分離的目錄。把所有測試類和待測類都放在同一個(gè)包中，但使用平行目錄結(jié)構(gòu)，為了可以訪問保護(hù)型的方法，需要把測試和待測類放在同一個(gè)包中，為了簡化文件管理，并讓人清晰的分辨測試類和開發(fā)代碼類，所有需要把測試放在一個(gè)單獨(dú)的目錄中。當(dāng)然我們也可以使用一個(gè)test的包，進(jìn)行遺漏所有開發(fā)包。這樣也可以把test需要的resources文件也可也獨(dú)立起來。
9.存在三種單元測試：邏輯單元測試，集成單元測試，功能單元測試。邏輯單元測試主要是檢查代碼邏輯性，通常只是針對單個(gè)方法，一般可以通過mock objects 和stub 來控制特定的方法的邊界。集成單元測試主要是在真實(shí)環(huán)境下的一個(gè)組件相互交互的測試。功能單元測試目的是為了確認(rèn)響應(yīng)的結(jié)果是否正確，這種單元測試更多的依賴于外部環(huán)境。
10.考察單元測試的覆蓋率。一種方法是數(shù)一下你的測試中用到了多少方法。使用Clover工具進(jìn)行覆蓋率統(tǒng)計(jì)，記住的測試覆蓋并不能保證你的應(yīng)用程序得到了的測試。
11.測試先行。在寫任何代碼之前，必須先寫一個(gè)失敗的測試。為啥是失敗的測試呢，因?yàn)椴皇鞘〉臏y試，老是成功的測試，你不會改進(jìn)這些代碼來使其更加具有維護(hù)性。
