單元測試是什麼

單元測試是開發者編寫的一小段程式碼，用於檢驗被測程式碼的一個很小的、很明確的功能是否正確，通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函式的行為1。

單元測試的好處

1，單元測試不但會使你的工作完成得更輕鬆。而且會令你的設計會變得更好，甚至大大減少你花在除錯上面的時間
2，提高程式碼質量
3，減少bug，快速定位bug
4，放心地修改、重構
5，顯得專業（玩笑話）

寫單元測試要注意什麼

1，不能只測試一條正確執行路徑，要考慮到所有可能的情況
2，要確保所有測試都能夠通過，避免間接損害
3，如果一個函式複雜到無法單測，那就說明模組的抽象有問題
4，配置不是單元測試的難點，難點是mock（後文講），做單元測試需要偽造被測函式用到的大部分函式

間接損害：在整個系統中，當某一部分加入了新特性，或者修復了一個bug之後，給系統的其他（與前面可能是互不相關的）部分引入了一個新的bug（或者損害）。如果無視這種損害並且繼續開發的話，那麼將可能帶來一個很危險的問題，最後可能會導致整個系統崩潰，並且沒人能夠修復。

為什麼寫單元測試（為什麼會拒絕單元測試）

編寫單元測試太花時間了？考慮下面問題：

1，對於所編寫的程式碼，你在除錯上面畫了多少時間？
2，對於以前你自認為正確的程式碼，而實際上這些程式碼卻存在重大的bug，你畫了多少時間在重新確認這些程式碼上面？
3，對於一個別人報告的bug，你花了多少時間才找出導致這個bug的原始碼位置？
對於那些沒有使用單元測試的程式設計師而言，上面這些問題所耗費的時間的遞增速度是很快的，而且隨著專案深入，遞增速度會變得更快；而另一方面，適當的單元測試卻可以很大程度地減少這些時間，從而為你騰出足夠的時間來編寫所有的單元測試——甚至可能還有剩餘的空閒時間。

執行測試的時間太長？

一般合適的測試是不會讓這種情況發生的。
有些真的會花很長時間的，可以把耗時的測試和其他測試分開。

不清楚程式碼的行為？

如果實在不清楚程式碼的行為，那麼現在應該也不是應該編碼的時候。

程式碼都能編譯通過啊？

ok，你的程式碼語法正確，應該也是可以執行的。但是程式碼的行為和你的預期是一樣的麼？

public void addItem(Object itemObject){
    List myList = new List;
    myList.add(itemObject);
    myList.add(itemObject);
    ...
 

}

你真的想把同一個物件加到 list 兩次麼？或許是，或許不是，但是編譯器並不能告訴你程式碼是否完成了你所期望的功能。

1. 單元測試之道Java版——使用JUnit ↩