Android 進行單元測試難在哪-終，android單元測試

Android 進行單元測試難在哪-終，android單元測試

• 原文連結 : WHAT I’VE LEARNED FROM TRYING TO MAKE AN ANDROID APP UNIT TESTABLE
• 原文作者 : Matthew Dupree
• 譯文出自 : 開發技術前線 www.devtf.cn
• 譯者 : chaossss
• 校對者: Mr.Simple
• 狀態 : 完成

在前面的博文中，我給大家介紹並展示了要怎麼使用 Square 大法架構 Android 應用，事實上，Square 開發新的 Android 應用架構本意只是增強應用的可測試性。正如我在Android 進行單元測試難在哪-序中所說，要在 Android 中進行單元測試在大多數情況下都很費時，嘗試一些奇技淫巧或者第三方庫情況可能會好一些。為了實現高效且不依賴第三方庫的測試單元，Square 大法應運而生。

此外，我們在 Android 進行單元測試難在哪-part1和 Android 進行單元測試難在哪-part3兩篇博文就這個問題進行了研究，最後成功地通過 Square 大法為 Android 應用實現了測試單元，這篇文章則是對 Square 大法進行評估，我將從下面三個方面進行：

移除所有對 Android SDK 的編譯時間依賴既不必要也不切合實際

完成這個系列博文的最初願望就是通過讓 Android 應用棧變成那樣，增強應用的可測試性：

接下來我將告訴大家，這個想法一直誤導著我們。要使應用的可測試性增強，我們還需要利用依賴注入的其它特性，而不僅僅是用它將商務邏輯代碼和 Android SDK 解耦。最初的原因是對象的 Android 依賴可以通過類似 Mockito 的東西類比出來，而且如果我們無法單獨通過 Mocktio 完全控制測試單元的預測試狀態的話，我們還可以用具有 mock 實現的介面代替這些 Android 依賴。而這也正是我們在 Android 進行單元測試難在哪-part4中重構 SessionRepositoryManager 的辦法。

移除依賴不僅是不必要的，將它完全與 Android SDK 解耦也是不切實際的，問題在於：當你嘗試完成這個目標時，不妨回顧你已經完成的工作，你會很明顯地感覺這是不必要的，所以我只打算在此簡要地陳述個中因由。

要移除移除應用中所有對 Android SDK 的編譯時間依賴可能會導致下面的問題：

雖然 Square 大法存在一些問題，但這並不影響我在之前的博文中有關 Square 的講解，Square 的這些特性依舊是實用，值得嘗試的。由於 Android SDK 供予我們使用的應用組件類都沒有被依賴注入，我們要在 Android 應用中進行單元測試確實很困難，但有了 Square 大法後，只要我們將商務邏輯交給被依賴注入的純 Java 對象，就能輕易地對 Android 應用進行單元測試。儘管 Square 大法減小了移除 Android SDK 依賴的需求，但 Square 大法仍然是增強應用可測試性的屠龍寶刀。但我個人還是希望對 Square 大法進行最佳化，使得 Square 大法能無視這個需求，換句話說，我希望能夠找到一種不需要我們移除所有對 Android SDK 依賴的架構方法，

乏味的模板代碼是阻礙應用變得可測試的絆腳石

如果我們對 Square 大法進行最佳化，使其不再要求我們移除對 Android SDK的依賴，Square 大法看起來真的是天下第一的神功了。委以商務邏輯的純 Java 對象將被應用組件類引用，使它們能夠訪問所有組件類內的屬性和回調。因此，將商務邏輯轉移到進行了依賴注入的純 Java 對象，不應該將那些擁有履行自身職責的資料的對象排除在外。

如果這是正確的，那麼唯一阻止我們使用 Square 大法的就是實現乏味的模板代碼。幸運的是，Android Studio 為我們提供了過渡到 Square 大法的重構選項——the Extract Delegate option。利用這個選項，可以自動地將類的方法和執行個體變數轉移到一個委託類中，並讓原始類通過調用委託類處理邏輯，而不用依賴類自身的方法。

這個視頻向我們展示了如何利用 the Extract Delegate option 完成重構 SessionDetailActivity 的 onStop() 並使之能夠進行單元測試必要的操作。我曾在之前的博文中給大家解釋過進行這樣的重構為什麼是必要的，很顯然，手動操作無法涵蓋所有情況，而且你需要為此不斷重複實現代碼語句塊中分離 Activity View 和資料的方法，這樣重複而又沒有意義的工作無異於浪費生命，因此這個選項真的非常實用。

依賴注入是 Square 大法的精髓

Android 進行單元測試難在哪-part3的秘密在於：依賴注入。

— Chris Arriola (@arriolachris) May 15, 2015

Square 大法之所以能解決 Android 的單元測試問題，是因為它允許我們對持有商務邏輯的類進行真正的依賴注入，我之所以強調 Square 允許我們進行的是真正的依賴注入，是因為依賴注入這個概念在 Dagger 庫中也被提到過，然而，Dagger 並不能真正簡化 Android 應用進行單元測試的代碼。

這是因為 Dagger 就像它介紹的那樣，確實是一個 Service 定位庫，正是如此，Dagger 強迫我們實現一個模組，使之為我們想要進行單元測試的對象提供 mock 依賴。為了能利用這些模組，我們還要確保由這些 mock 提供者模組構建的對象圖與我們嘗試進行單元測試的對象使用的對象圖相同。

而正是這樣的操作使得 Dagger 的依賴注入不如 Square 大法中真正的依賴注入那樣簡便，解釋為什麼 Dagger 不能簡化對 Android 應用進行單元測試的過程完全可以寫一篇博文，所以現在，我唯一能做的就是先指出這個問題，如果我們理解 Martin Fowler 對依賴注入的定義（這篇博文確實值得一讀，因為他建立了一個新的術語），就會發現 Dagger 確實只是一個 Service 定位庫，而且 Google 官方有關測試的部落格也有一篇博文對此作出解釋。

結論

如果想讓 Android 應用可以進行單元測試，那就用 Square 大法吧，當然了，如果有其他解決辦法的話我也會支援的。在這裡友情提示一下哈：我只是列出我瞭解的幾種辦法，我可沒有說 Square 大法天下第一無人可敵，事實上增強應用可測試性應該還會有其他辦法的。

這篇博文的發布也預示著這系列博文走向終結啦，我非常感謝每一個關注本系列博文的 Android 開發人員的支援，感謝每一個人對我的鼓勵、轉寄以及大家在社交媒體上對我的褒獎，我感恩這一切。這些積極的反饋使我認識到討論和思考對 Android 應用進行測試的重要性，正是完成這個系列博文給我帶來的啟示使我決定：我要在未來花費更多的時間在部落格中研究 Android 測試方面的知識。我會在每個周五更新部落格，希望能學習更多有關測試的知識，和大家一起進步。