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

標籤：android   單元測試   

• 原文連結 : HOW TO MAKE OUR ANDROID APPS UNIT TESTABLE (PT. 1)
• 原文作者 : Matthew Dupree
• 譯文出自 : 開發技術前線 www.devtf.cn
• 譯者 : chaossss
• 校對者: tiiime
• 狀態 : 完成

在 Android 應用中進行單元測試很困難，有時候甚至是不可能的。在之前的兩篇博文中，我已經向大家解釋了在 Android 中進行單元測試如此困難的原因。而上一篇博文我們通過分析得到的結論是：正是 Google 官方所提倡的應用架構方式使得在 Android 中進行單元測試變成一場災難。因為在官方提倡的架構方式中，Google 似乎希望我們將商務邏輯都放在應用的組件類中（例如：Activity，Fragment，Service，等等……）。而這種開發方式也是我們一直以來使用的開發模板。

在這篇博文中，我列舉出幾種架構 Android 應用的方法，使用這些方法進行開發能讓單元測試變得輕鬆些。但正如我在序中所說，我最推崇的辦法始終是 Square 發布的博文： Square：從今天開始拋棄Fragment吧！ 中所用的通用方法。因為這個方法是由 Square 中的 Android 開發工程師想出來的，所以我會在接下來的博文中將這個辦法叫作“Square 大法”。

Square 大法的核心思想是：把應用組件類中的商務邏輯全部移除（例如：Activity，Fragment，Service，等等……），並且把商務邏輯轉移到業務對象，而這些業務對象都是被依賴注入的純 Java 對象，以及與 Android 無關的介面在此的 Android 特定實現。如果我們在開發應用的時候使用 Square 大法，那進行單元測試就簡單多了。在這篇博文中，我會解釋 Square 大法是如何協助我們重構 UI 無關的應用組件（例如我們在之前的博文中討論的 SessionCalendarService），並讓對它進行單元測試變得容易許多。

用 Square 大法重構 UI 無關的應用組件

用 Square 大法重構類似於 Service，ContentProvider，BroadcastReceiver這樣的 UI 無關的應用組件相對來說比較容易。我再說一次我們要做的事情吧：把在這些類中的商務邏輯移除，並把它們放到業務對象中。

由於“商務邏輯”是很容易有歧義的詞語，我來解釋下我使用“商務邏輯”這個詞時，它所代表的含義吧。當我提到“商務邏輯”，它的含義和維基百科上的解釋是一致的：程式中根據現實世界中的規則用於決定資料將如何被建立，展示，儲存和修改的那部分代碼。那麼現在我們就可以就“商務邏輯”這個詞的含義達成共識了，那就來看看 Square 大法到底是啥吧。

我們先來看看怎麼用 Square 大法實現我在之前的博文中介紹的 SessionCalendarService 吧，具體代碼如下：

/** * Background {@link android.app.Service} that adds or removes session Calendar events through * the {@link CalendarContract} API available in Android 4.0 or above. */public class SessionCalendarService extends IntentService {    private static final String TAG = makeLogTag(SessionCalendarService.class);    //...    public SessionCalendarService() {        super(TAG);    }    @Override    protected void onHandleIntent(Intent intent) {        final String action = intent.getAction();        Log.d(TAG, "Received intent: " + action);        final ContentResolver resolver = getContentResolver();        boolean isAddEvent = false;        if (ACTION_ADD_SESSION_CALENDAR.equals(action)) {            isAddEvent = true;        } else if (ACTION_REMOVE_SESSION_CALENDAR.equals(action)) {            isAddEvent = false;        } else if (ACTION_UPDATE_ALL_SESSIONS_CALENDAR.equals(action) &&                PrefUtils.shouldSyncCalendar(this)) {            try {                getContentResolver().applyBatch(CalendarContract.AUTHORITY,                        processAllSessionsCalendar(resolver, getCalendarId(intent)));                sendBroadcast(new Intent(                        SessionCalendarService.ACTION_UPDATE_ALL_SESSIONS_CALENDAR_COMPLETED));            } catch (RemoteException e) {                LOGE(TAG, "Error adding all sessions to Google Calendar", e);            } catch (OperationApplicationException e) {                LOGE(TAG, "Error adding all sessions to Google Calendar", e);            }        } else if (ACTION_CLEAR_ALL_SESSIONS_CALENDAR.equals(action)) {            try {                getContentResolver().applyBatch(CalendarContract.AUTHORITY,                        processClearAllSessions(resolver, getCalendarId(intent)));            } catch (RemoteException e) {                LOGE(TAG, "Error clearing all sessions from Google Calendar", e);            } catch (OperationApplicationException e) {                LOGE(TAG, "Error clearing all sessions from Google Calendar", e);            }        } else {            return;        }        final Uri uri = intent.getData();        final Bundle extras = intent.getExtras();        if (uri == null || extras == null || !PrefUtils.shouldSyncCalendar(this)) {            return;        }        try {            resolver.applyBatch(CalendarContract.AUTHORITY,                    processSessionCalendar(resolver, getCalendarId(intent), isAddEvent, uri,                            extras.getLong(EXTRA_SESSION_START),                            extras.getLong(EXTRA_SESSION_END),                            extras.getString(EXTRA_SESSION_TITLE),                            extras.getString(EXTRA_SESSION_ROOM)));        } catch (RemoteException e) {            LOGE(TAG, "Error adding session to Google Calendar", e);        } catch (OperationApplicationException e) {            LOGE(TAG, "Error adding session to Google Calendar", e);        }    }    //...}

如你所見，SessionCalendarService 調用了將要在後面定義的 helper 方法。一旦我們將這些 helper 方法和類的欄位聲明也考慮進來，Service 類的代碼就有400多行。要 hold 住這麼龐大的類內發生的商務邏輯可不是什麼簡單的活，而且就像我們在上一篇博文中看到的那樣，要在 SessionCalendarService 中進行單元測試簡直是天方夜譚。

那現在來看看用 Square 大法實現它代碼會是怎樣的。我再強調一次：Square 大法需要我們將 Android 類內的商務邏輯遷移到一個業務對象中。在這裡，SessionCalendarService 所對應的業務對象則是 SessionCalendarUpdater，具體代碼如下：

public class SessionCalendarUpdater {    //...    private SessionCalendarDatabase mSessionCalendarDatabase;    private SessionCalendarUserPreferences mSessionCalendarUserPreferences;    public SessionCalendarUpdater(SessionCalendarDatabase sessionCalendarDatabase,                                  SessionCalendarUserPreferences sessionCalendarUserPreferences) {        mSessionCalendarDatabase = sessionCalendarDatabase;        mSessionCalendarUserPreferences = sessionCalendarUserPreferences;    }    public void updateCalendar(CalendarUpdateRequest calendarUpdateRequest) {        boolean isAddEvent = false;        String action = calendarUpdateRequest.getAction();        long calendarId = calendarUpdateRequest.getCalendarId();        if (ACTION_ADD_SESSION_CALENDAR.equals(action)) {            isAddEvent = true;        } else if (ACTION_REMOVE_SESSION_CALENDAR.equals(action)) {            isAddEvent = false;        } else if (ACTION_UPDATE_ALL_SESSIONS_CALENDAR.equals(action)                && mSessionCalendarUserPreferences.shouldSyncCalendar()) {            try {                mSessionCalendarDatabase.updateAllSessions(calendarId);            } catch (RemoteException | OperationApplicationException e) {                LOGE(TAG, "Error adding all sessions to Google Calendar", e);            }        } else if (ACTION_CLEAR_ALL_SESSIONS_CALENDAR.equals(action)) {            try {                mSessionCalendarDatabase.clearAllSessions(calendarId);            } catch (RemoteException | OperationApplicationException e) {                LOGE(TAG, "Error clearing all sessions from Google Calendar", e);            }        } else {            return;        }        if (!shouldUpdateCalendarSession(calendarUpdateRequest, mSessionCalendarUserPreferences)) {            return;        }        try {            CalendarSession calendarSessionToUpdate = calendarUpdateRequest.getCalendarSessionToUpdate();            if (isAddEvent) {                mSessionCalendarDatabase.addCalendarSession(calendarId, calendarSessionToUpdate);            } else {                mSessionCalendarDatabase.removeCalendarSession(calendarId, calendarSessionToUpdate);            }        } catch (RemoteException | OperationApplicationException e) {            LOGE(TAG, "Error adding session to Google Calendar", e);        }    }    private boolean shouldUpdateCalendarSession(CalendarUpdateRequest calendarUpdateRequest,                                                 SessionCalendarUserPreferences sessionCalendarUserPreferences) {        return calendarUpdateRequest.getCalendarSessionToUpdate() == null || !sessionCalendarUserPreferences.shouldSyncCalendar();    }}

我想要強調其中的一些要點：首先，需要注意，我們完全不需要用到任何新的關鍵字，因為業務對象的依賴都被注入了，它根本不會使用新的關鍵字，而這正是讓類可單元測試的關鍵。其次，你會注意到類沒有確切地依賴於 Android SDK，因為業務對象的依賴都是 Android 無關介面的 Android 特定實現，因此它不需要依賴於 Android SDK。

那麼這些依賴是怎麼添加到　SessionCalendarUpdater　類中的呢？是通過　SessionCalendarService　類注入進去的：

/** * Background {@link android.app.Service} that adds or removes session Calendar events through * the {@link CalendarContract} API available in Android 4.0 or above. */public class SessionCalendarService extends IntentService {    private static final String TAG = makeLogTag(SessionCalendarService.class);    public SessionCalendarService() {        super(TAG);    }    @Override    protected void onHandleIntent(Intent intent) {        final String action = intent.getAction();        Log.d(TAG, "Received intent: " + action);        final ContentResolver resolver = getContentResolver();        Broadcaster broadcaster = new AndroidBroadcaster(this);        SessionCalendarDatabase sessionCalendarDatabase = new AndroidSessionCalendarDatabase(resolver,                                                                                             broadcaster);        SharedPreferences defaultSharedPreferences = PreferenceManager.getDefaultSharedPreferences(this);        SessionCalendarUserPreferences sessionCalendarUserPreferences = new AndroidSessionCalendarUserPreferences(defaultSharedPreferences);        SessionCalendarUpdater sessionCalendarUpdater                                    = new SessionCalendarUpdater(sessionCalendarDatabase,                                                                 sessionCalendarUserPreferences);        AccountNameRepository accountNameRepository = new AndroidAccountNameRepository(intent, this);        String accountName = accountNameRepository.getAccountName();        long calendarId = sessionCalendarDatabase.getCalendarId(accountName);        CalendarSession calendarSessionToUpdate = CalendarSession.fromIntent(intent);        CalendarUpdateRequest calendarUpdateRequest = new CalendarUpdateRequest(action, calendarId, calendarSessionToUpdate);        sessionCalendarUpdater.updateCalendar(calendarUpdateRequest);    }}

值得注意的是，修改後的 SessionCalendarService 到處都是新的關鍵字，但這些關鍵字在類中並不會引起什麼問題。如果我們花幾秒時間略讀一下要點就會明白這一點：SessionCalendarService 類中已經沒有任何商務邏輯，因此 SessionCalendarService 類不再需要進行單元測試。只要我們確定在 SessionCalendarService 調用的是 SessionCalendarUpdater 類中的 updateCalendar() 方法，在 SessionCalendarService 唯一可能出現的就是編譯時間錯誤。我們完全不需要為此實現測試單元，因為這是編譯器的工作，與我們無關。

由於我在前兩篇博文中提到的相關原因，將我們的 Service 類拆分成這樣會使對商務邏輯進行單元測試變得非常簡單，例如我們對 SessionCalendarUpdater 類進行單元測試的代碼可以寫成下面的樣子：

public class SessionCalendarUpdaterTests extends TestCase {    public void testShouldClearAllSessions() throws RemoteException, OperationApplicationException {        SessionCalendarDatabase sessionCalendarDatabase = mock(SessionCalendarDatabase.class);        SessionCalendarUserPreferences sessionCalendarUserPreferences = mock(SessionCalendarUserPreferences.class);        SessionCalendarUpdater sessionCalendarUpdater = new SessionCalendarUpdater(sessionCalendarDatabase,                                                                                   sessionCalendarUserPreferences);        CalendarUpdateRequest calendarUpdateRequest = new CalendarUpdateRequest(SessionCalendarUpdater.ACTION_CLEAR_ALL_SESSIONS_CALENDAR,                                                                                0,                                                                                null);        sessionCalendarUpdater.updateCalendar(calendarUpdateRequest);        verify(sessionCalendarDatabase).clearAllSessions(0);    }}

結論

為了能夠進行單元測試，我認為修改後的代碼變得更易讀和更易維護了。可以肯定的是，我們還有許多辦法能讓代碼變得更好，但在讓代碼能夠進行單元測試的過程中，我想讓修改後的代碼儘可能與修改前風格相似，所以我沒有進行其他修改。在下一篇博文中，我將會教大家如何使用 Square 大法重構應用的 UI 組件（例如：Fragment 和 Activity）。

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