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

原文鏈接 : 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）。