Android 進行單元測試難在哪-序

標籤：單元測試   android   

• 原文連結 : Against Android Unit Tests
• 原文作者 : Matthew Dupree
• 譯文出自 : 開發技術前線 www.devtf.cn
• 譯者 : chaossss
• 校對者: Rocko
• 狀態 : 完成

其實不僅僅只有普通 Android 開發工程師覺得測試 Android 應用很惱火，大牛們也受此困擾已久。例如 Jake Wharton 曾經明確地表示：Android 平台自誕生之初就與應用測試勢如水火。Don Felker 和 Kaushik Gopal 也在他們的博文裡也提出了相同的觀點。當然了，他們還提到 Google 的 IOSched 應用，根本就沒有進行過測試，據說 IOSched 還是 Android 開發環境中應用開發的最優集合體呢。IOSched 沒有進行測試讓我們這些開發人員很困擾：1、Google 所謂的“測試是高效地進行 Android 開發中的關鍵一環”真的不是來唬小孩的嗎；2、還是 Google 官方的工程師覺得測試 Android 應用簡直就是浪費時間？不管怎樣，如果這個世界上最優秀的 Android 開發工程師都覺得在 Android 中進行測試很麻煩，那我們這些小菜雞玩不好測試也是理所當然的了。

多年以來，Android 開發人員們為克服在 Android 中難於進行測試的問題絞盡腦汁。Roboletric 就是這些工程師的智慧結晶，它能讓開發人員們在 JVM 虛擬機器上進行 Android 測試。而最近又有博文開始聲討 Fragment，個中翹楚 Square 就表示：老子再也不用 Fragment 這種垃圾玩意了，我們要把商務邏輯都轉換到新開發的 Mortar & Flow （MVP 開發架構）架構裡，用純 Java 對象進行編程，完全不依賴 Android 平台的 API。毫無疑問，這些 Java 對象在標準的 Java 測試載入器中進行測試是非常簡單的。

我堅信那些和 Square 站在統一戰線上的Team Dev肯定也在想辦法將 UI 從實際的商務邏輯中剝離為純 Java對象，為提高應用的可測試性不懈努力。換句話說，我覺得我們可以不在 Android 中進行單元測試，也不用實現依賴於 Android SDK 的測試單元。我們應該做的是重構應用，讓我們能夠為應用中的代碼實現純 Java 的測試單元，無論最終能不能真正地提高 Android 的可測試性和健壯性，我覺得這都值得一試。

我感覺到這個思路會是治本良方，所以我們要做的，就是將這樣的 Android 的應用架構

變成這樣：

雖然這個方法可能能從根本上解決問題，但它也有很大的風險，儘管如此，我還是堅持認為這個方法值得一試，因為它能拯救萬千掙紮在實現 Android 測試單元的開發人員們於水火之中，而且不用強迫他們使用第三方的庫，畢竟第三庫總會讓他們滯後於最新的 Android 系統特性。此外，Kent Beck 認為：可測試性好的代碼就是架構優秀的代碼，如果他的觀點是對的，或許我們還能找到架構應用更好的辦法。

在接下來的博文裡，我將探索“重構 Android 應用以使它們能輕易地通過標準的 Java 工具進行測試”這個方案的可操作性。

在第一、第二篇博文中，我會側重闡述在 Android 裡進行單元測試為什麼會帶來如此痛苦的體驗。我覺得阻礙 Android 測試方法發展的根本原因就在於：Android 系統本身就難於進行測試。缺乏對 Activity 和 Fragment 的合理注入就是讓應用難以測試的根本原因，而且認識到這一點是設計可測試強的應用架構的關鍵。

在第三篇博文中，我會在細節上探討一個常見的解耦應用代碼和 Android SDK的策略。簡單來說，這個策略就是：將所有應用的具體行為交給一個 POJO 對象（Plain Ordinary Java Object）完成，這些 POJO 對象都是 Android 無關的介面的 Android 特定實現。

在第四篇博文中，我會指出實現第二篇博文中提出的策略存在的技術痛點，並嘗試去挖掘可以解決這些痛點的方法。在這些痛點中，最大的問題在於記憶體流失和繁複的重用代碼。

在最後一篇博文中，我會通過展示我提出的架構為 Android 測試性帶來的提高讓大家覺得進行這樣的技術探索是值得花費時間、精力，並且能獲得相應回報的。

Android 進行單元測試難在哪-序