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的核心思想是測試先來，實現後來。但如何測試並沒有列規定非要用代碼，所以根據實際情況，選擇最佳的測試手段。