單元測試在Android開發中存在意義在哪裡?

01-04

我來回答下我的感受吧：我確實從沒有在Android開發里用過單元測試。後來看了一些bob大叔的書，還看了一些GUI方面的書，如wxpython in action之類的。其實很多人都提到過，GUI系統其實是蠻難單元測試的，我到現在也沒看到哪個體系有完整的單元測試，說覆蓋率100%的。

前不久，我仍不死心，想找一下相關的單元測試框架，能用於Android，還要求好用，寫的測試代碼不要比寫的開發代碼多，能完美結合Android的。不過我真的沒找到好的框架。

後來我總結了下：

[Android測試的難點]

1. 寫測試的代碼太多。也要findviewbyid, 也要做設置，寫完一個複雜的場景，要寫的測試代碼實在太多

2. 四大組件有生命周期。一個簡單的按Home鍵操作，再出去，再回來操作，這個就無法捕捉到所有on**系列的生命周期方法

3. UI上的東西，比如這個文字沒有對齊，只有人能看到。不可能對著視覺規範稿，一一地寫測試代碼。這樣寫一個是測試代碼太多，二是不同解析度的手機上可能有問題，一些手機能通過測試，一些手機就fail掉了。

4. 非同步的問題。開啟了一個AsyncTask後，可能還能有onPostExecute()。那要是一個自定義線程，測試代碼我就沒有辦法知道這個線程什麼時候做完了。

我覺得資料庫操作，文件操作可能還是適合單元測試的，但涉及到界面的，怕沒這麼適用了。

所以，現在正式回答題主的問題：單元測試很好，可以干一些重複性的活，讓我們敢修改，敢重構，改完之後還能迅速知道自己有沒有改對。也能讓整個應用的質量提高。

但是，我個人覺得Android這些GUI系統上的單元測試不太容易。如果誰有Android上單元測試的好範例，或是好框架，請一定指點下我，多謝了。

題主，請你先說說什麼是你認為的「單元測試」？

簡單來說：

測試驅動和具體的開發平台並無關係，不管是 Android 還是 Python Web，一個好的測試習慣能夠節省大量的 debug 時間，只要在我能控制的項目上，我是要求必須寫測試用例的(最低是單測)。

當然，不同的測試粒度，適用於不同的項目，而且每個人對測試的劃分理解也不同，以下是我個人的一些看法：

1. 單元測試

一般我們稱為一個封閉的功能點為一個單元，比如一個求餘弦相似度的函數，一個調用伺服器API登陸的介面等等，都可以成為一個單元。

通常來說，不管任何規模的項目，我個人建議充分編寫這個層級的測試用例，這是因為單元代碼應該是改動頻率最低的，否則大多是設計有問題。

這類測試通常覆蓋幾乎100%的條件分支。

2. 功能測試

一個完整的功能點，通常集合多個不同的單元，比如登陸流程，設計到用戶輸入校驗、發送請求、響應解析，可以作為一個功能點來測試。

由於這類功能邏輯通暢會隨著業務調整而變化，所以這類測試一般不要求過大的覆蓋率，否則工作量太大，適得其反。我個人的做法是對這樣的邏輯做正反兩個主分支即可（即成功或失敗）

3. 集成測試

這類測試往往是手動測試，也有一些自動化測試的腳本工具，如 Selenium 等，這類測試一般不建議開發人員自己編寫，而是由測試團隊根據測試用例進行編寫測試，充分發揮各自特長。

附圖是我很久以前編寫的一個 Android 即時通訊程序的功能測試，實踐中為我節省了大量的 debug 時間（即時通訊的 bug 很難調，有經驗的朋友應該知道，尤其這個是自己設計的通訊協議）：

從來不做單元測試，你開發完一個功能，然後自己裝機玩一下，看和產品的需求是否一致，如果一致的話基本就不會有太大問題了。

Android開發的內容說白了就是「在客戶端進行數據的展示」，雖然也有邏輯但是並不會太複雜。我認為檢查ui的重要性甚至大於邏輯，比如說屏幕適配，這東西想要實現自動化測試並不容易，還不如在機器上自己調試。

抱歉，我沒有專門搞過很多Android開發。不過照我的理解，你單測都跑不通，就別出去害同事了好不好？

說實話，做安卓2年也沒有寫過單元測試的代碼，app跑起來測試功能點是否有效，打個log其實要比寫一大堆測試代碼簡單得多

單元測試還是大型的web項目或者pc的程序更適合些吧

寫過1年Android單元測試的我，

截止目前這個時間點

真心的說一句，

邏輯和顯示完全分離的Android項目可以寫UT（僅對邏輯寫UT），

不然，別寫。

真的費勁，而且無用。

有多少android開發是做單元測試的反正我是沒見過。。。

用資料庫我寫過一次，呃，第一個項目。後來項目周期問題就真沒寫過了。部署到設備上跑幾次結束。自動化test case代碼太浪費時間了。qa組那邊的頭頭會寫，要需要提測之後那邊會搞定。