很多開發人員，特別是小公司的開發人員，基本上從來不用
單元測試，認為直接開發既快又好，還要做單元測試浪費時間和精力。但大公司相反，比較看重單元測試。因為有單元測試的代碼，相對穩定可靠，而且如果開發人員習慣了以測試為驅動的開發，也會覺得這樣的方式很不錯。
以測試為驅動的開發模式是：開發之前，先想好要做什么，然后把對外的接口設計好，就可以先寫單元測試的代碼。之后再進行實際代碼的開發，開發完成之后，再跑一遍之前寫的單元測試，如果失敗則調試，直到最終成功，會讓開發人員特有成就感。
單元測試也特別適合于
敏捷開發，開發新的功能以后，你不知道會不會對以前已經穩定的功能產生影響。當然你可以手工測試一下，但一次兩次手工測試沒問題，多了就會發現還是單元測試好，自動跑一遍就行，更符合程序員善于使用工具的優秀品質。
單元測試的工具，
Android上使用junit加上ant腳本配合，ios上使用ocunit或者ghunit。雖然工具不同，但思想類似。
當然，并不是所有項目都一定要做單元測試最好。本人以前的項目，有用單元測試的，也有不用的，這里總結一下使用單元測試的2個原則。
1. 項目的規模原則。 如果是小項目，開發完就扔給客戶，后期基本不用維護。那就偏向于直接開發，極快又好，你做得單元測試再多客戶也看不見，做的快還能被客戶夸。如果是大項目，你做第n個模塊的時候，第1個模塊的細節已經忘得差不多了，那這時候有單元測試可以幫助你確認前面模塊的可靠性。
2. 因人而異原則。每個人的開發水平和性格不一樣，有些人天性謹慎，開發的代碼bug比較少，有些人比較粗放，bug就相對比較多。有了bug就需要測試和調試，當測試和調試的時間大于開發的時間時，建議下個項目使用單元測試模式開發。單元測試可以盡早讓你發現代碼中的問題，bug越早發現越容易解決。