關于android/ios開發中的單元測試

很多開發人員，特别是小公司的開發人員，基本上從來不用單元測試，認為直接開發既快又好，還要做單元測試浪費時間和精力。但大公司相反，比較看重單元測試。因為有單元測試的代碼，相對穩定可靠，而且如果開發人員習慣了以測試為驅動的開發，也會覺得這樣的方式很不錯。

　　以測試為驅動的開發模式是：開發之前，先想好要做什麼，然後把對外的接口設計好，就可以先寫單元測試的代碼。之後再進行實際代碼的開發，開發完成之後，再跑一遍之前寫的單元測試，如果失敗則調試，直到最終成功，會讓開發人員特有成就感。

　　單元測試也特别适合于靈活開發，開發新的功能以後，你不知道會不會對以前已經穩定的功能産生影響。當然你可以手工測試一下，但一次兩次手工測試沒問題，多了就會發現還是單元測試好，自動跑一遍就行，更符合程式員善于使用工具的優秀品質。

　　單元測試的工具，android上使用junit加上ant腳本配合，ios上使用ocunit或者ghunit。雖然工具不同，但思想類似。

　　當然，并不是所有項目都一定要做單元測試最好。本人以前的項目，有用單元測試的，也有不用的，這裡總結一下使用單元測試的2個原則。

　　1. 項目的規模原則。 如果是小項目，開發完就扔給客戶，後期基本不用維護。那就偏向于直接開發，極快又好，你做得單元測試再多客戶也看不見，做的快還能被客戶誇。如果是大項目，你做第n個子產品的時候，第1個子產品的細節已經忘得差不多了，那這時候有單元測試可以幫助你确認前面子產品的可靠性。

　　2. 因人而異原則。每個人的開發水準和性格不一樣，有些人天性謹慎，開發的代碼bug比較少，有些人比較粗放，bug就相對比較多。有了bug就需要測試和調試，當測試和調試的時間大于開發的時間時，建議下個項目使用單元測試模式開發。單元測試可以盡早讓你發現代碼中的問題，bug越早發現越容易解決。