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

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

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

　　這樣測試當然可以，只是它有如下的缺點：

　　1、將整個軟件啟動起來，通常要花很長的時間，這會影響你寫代碼的思路。每改動一點東西，要花很長時間才能看到效果，反饋時間過長。

　　2、類的某些邊界情況無法測試。

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

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