JUnit的測(cè)試案例誰都會(huì)寫，但是用JUnit寫的測(cè)試案例不一定是單元測(cè)試。單元測(cè)試是什么？應(yīng)該測(cè)什么？本文拋磚引玉，談點(diǎn)自己的想法。

　　單元測(cè)試，顧名思義是對(duì)組成軟件的一個(gè)單元進(jìn)行測(cè)試。在面向?qū)ο箝_發(fā)的語言中，我們通常將類作為單元進(jìn)行測(cè)試。如果從一個(gè)更高的層次來看一個(gè)類，它無非是從類的外部取得一些輸入（Input），經(jīng)過這個(gè)類加工處理后，輸出一部分新的信息（Output）。類的核心是加工處理輸入信息的業(yè)務(wù)邏輯（Business Logic）。每個(gè)類都為整個(gè)軟件貢獻(xiàn)了一部分邏輯，所有類按照一定的方式組合起來形成了整個(gè)軟件。從這個(gè)角度來看，單元測(cè)試是在給定輸入的情況下，通過檢測(cè)輸出以測(cè)試這個(gè)類的業(yè)務(wù)邏輯是否正確。

　　古語說，“各人自掃門前雪，莫管他家瓦上霜”。做單元測(cè)試也是一樣，單元測(cè)試應(yīng)該關(guān)注這個(gè)類本身的邏輯，不應(yīng)過度關(guān)注和它有關(guān)聯(lián)的其他類或者依賴。如果你之前做“單元測(cè)試”的時(shí)候是把整個(gè)軟件啟動(dòng)起來，以驗(yàn)證你寫的那部分代碼的邏輯是否正確，那么你不僅測(cè)試了自己的那部分代碼，還做了部分的集成測(cè)試。

　　這樣測(cè)試當(dāng)然可以，只是它有如下的缺點(diǎn)：

　　1、將整個(gè)軟件啟動(dòng)起來，通常要花很長(zhǎng)的時(shí)間，這會(huì)影響你寫代碼的思路。每改動(dòng)一點(diǎn)東西，要花很長(zhǎng)時(shí)間才能看到效果，反饋時(shí)間過長(zhǎng)。

　　2、類的某些邊界情況無法測(cè)試。

　　3、如果軟件是UI相關(guān)的，這樣的測(cè)試是很難自動(dòng)化的，即使能做到自動(dòng)化，也很難維護(hù)。

　　因此，單元測(cè)試應(yīng)僅僅關(guān)注在這個(gè)類本身，通過模擬這個(gè)類的輸入和類的依賴，以測(cè)試這個(gè)類所提供的業(yè)務(wù)邏輯是否正確。只要單元測(cè)試能保證這個(gè)類在它所支持的不同輸入情況下都是正確的，那足夠了。至于類和其他類的集成是后續(xù)測(cè)試要來保證的。