Android開發筆記之:對實踐TDD的一些建議說明

最近部分采用了TDD的方法來開發一個模塊，小有收獲特此總結一下：
1. TDD的基本原則
TDD的最核心思想就是先明確需求，且用代碼的方式量化，明確需求標准，然後進行編碼實現以達成由代碼測試來衡量的標准。
那麼它要求，先把需要標准寫出來，每次只寫一個。編碼實現通過達到，並剛好滿足這個標准。這樣一點一點的迭代。
這樣有三個好處：一個是先明確標准，不至於我們迷失主題，偏離方向。有標准在檢測，保證代碼是正確的。僅滿足當前測試，不至於過早優化和過度設計。
2. TDD的難點
難點在於如何設計這個測試標准，
1）讓它足夠小，是一個需求單元；
2）成為標准，也就是如何檢測正確性；
3）就是如何在最大程度模擬真實運行的場景，而不是為了測試而寫出許多額外的工具，也就是說測試應該跟真實的項目代碼一樣，不應該有多余的東西。
這關鍵在於要分析挖掘需求，並細化需求。如果都像書中的例子那樣測試一些API那倒是很好寫，因為測試代碼跟真實的App代碼用一樣的方式來調用API，而且API的功能也會有明確的描述。但現實情況並非如此，比如很多框架就很難測試，很多對象和創建和控制都是由框架來做，你無法像控制。這就導致了很難寫測試用例。
還有就是多線程，由於線程帶來的不確定性，有很多偽失敗，這可以參考書，書中有方法。
3. Android中的TDD
老實說，在Android完全用TDD的方法來開發是不可能的。原因如下：
1. Android中的應用程序主要結構是四大組件：Service，Activity和Provider和Receiver這四東西的創建和銷毀都是由框架來控制。所以你不可能像書中例子那樣去測試它們，因為有些限制讓你無法用代碼來測試。
2. 有些東西是系統框架的回調或者很基本東西根本不用寫TestCase。比如View的Click/LongClick/Touch事件的處理之類的，或者Activity的生命周期回調，或者OptionsMenu/ContextMenu之類的。
3. SDK中的用於測試的API功能太弱
這就導致了，為了測試一個小功能需要做很多工作和寫很多代碼，遠大於直接實現。比如測試一個彈出的Dialog，如果直接實現很容易；但如果用代碼來測試就要多3,4倍的工作量，遠大於直接實現。
4. 那麼在Android中應該如何運用好TDD呢？以下是一些建議：
1. 使用Robotium
這是強大的工具，它比SDK中的東西可是方便的很多比如searchText，clickMenu之類的接口非常的方便和實用。
2. 自動測試+手動測試
同樣要遵循原則，但是對於測試用例，沒有必要完全用代碼來寫，可以部分手動測試：一般的原則來講如果自動測試比較方便的實現就寫TestCase，如果手動測試很方便就手動測試，這沒有死規則要看具體的情況。
比如，View的事件，Activity的事件，Activity的Menu，Dialog之類的與交互相關的東西，以及跨應用交互的用例最好手動來測試，因為這些東西用代碼來測試更麻煩。
但對於一些涉及數值，計算，量化等就用代碼來做。比如下載一個文件，設定好路徑後就可以直接用File對象來檢測文件是否下載成功。
3. Provider必須要測試
Provider提供的是API，它非常好測試也容易寫，又是一個項目的基本設施，所以必須要好好測試，否則如果在Activity上某條數據有問題，你必須要確定是顯示上出了問題還是Provider裡出了問題。通常CRUD必須測試，還有就是where語句，以及逆向測試，必須要檢測Uri的合法性等，還有就是要檢測對特殊字符的處理，比如'和"。
4. 除Service和Activity以外的東西，特別是自己實現的類似API的類，如果裡面涉及一些業務邏輯也要進行測試。這就跟書中的例子差不多了，測試的難易成就也取決於業務的分解，設計和耦合度了。
5. 用反射來測試類的內部
對於Service和Activity雖然可以在TestCase中拿到它的實例，但是Service和Activity是一個組件單元在實際中並不會Public太多的接口，它們是處於最頂端的調用其他接口，而自己不會，也不應該公開接口給別人用，原因就是它們的創建和生命周期的管理都是由系統控制的，別處不應該有太多對它們的引用。
那麼當要測試Service和Activity內部時怎麼辦呢？比如要測試某個Service內部的一個int[] mPlaylistQueue。我們總不能為了寫Case而在Service中加接口吧！這時就要用反射機制來取出這個成員的實例，然後檢查它的數據。
6. 有些東西必須手動測試，自動化無法完成
TestCase是有特殊的Context和MockObject的，它是對真實Android運行的一個最大化的模擬，它並不跟應用真正運行時的情況完全一樣！而且由於Permission的原因，某些事情Instrumentation是無法做的，比如Alarm，日期等Instrumentation是無權限更改的。這些必須要靠手動測試。
還有就是Service和Activity的初始化和銷毀，特別是銷毀，沒辦法測試，也就是說對於onDestroy()裡面的東西，還真的不好去測試。第一，你不知道它何時被回調到；第二，執行到它時對象快被銷毀了，你持有的引用不一定有效了；第三，成員對象是否都有效也無法得知。對於onDestroy只能通過調試手段手動的去測試。
總之，在我看來，TDD的核心思想是測試先來，實現後來。但如何測試並沒有列規定非要用代碼，所以根據實際情況，選擇最佳的測試手段。