【譯】使用Kotlin和RxJava測試MVP架構的完整示例 - 第3部分

阿新 • • 發佈：2018-12-29

原文連結：https://android.jlelse.eu/complete-example-of-testing-mvp-architecture-with-kotlin-and-rxjava-part-3-df4cf3838581

使用假資料和Espresso來建立UI測試

這是Android測試系列的最後一部分。如果你錯過了前2個部分，不用擔心，即使你沒有閱讀過，也可以理解這一點。如果你真的想看看，你可以從下面的連結找到它們。

Complete example of testing MVP architecture with Kotlin and RxJava — Part 1

Complete example of testing MVP architecture with Kotlin and RxJava — Part 2

在這部分中，您將學習如何使用假資料在Espresso中建立UI測試，如何模擬Mockito-Kotlin的依賴關係，以及如何模擬Android測試中的final 類。

注‘Android技術交流群878873098，歡迎大家加入交流，暢談！本群有免費學習資料視訊’並且免費分享原始碼解析視訊

用假資料編寫Espresso測試

如果我們想編寫始終產生相同的結果的UI測試，我們最需要做的事情就是使我們的測試獨立於來自網路或本地資料庫的任何資料。

在其他層面，我們可以通過模擬測試類的依賴來輕鬆實現這一點（正如你在前兩部分中看到的）。這在UI測試中有所不同。在前面的例子中，我們的類是從建構函式中得到了它們的依賴，所以我們可以很容易地將模擬物件傳遞給建構函式。而Android元件是由系統例項化的，通常是通過欄位注入獲得它們的依賴。

使用假資料建立UI測試有多種方法。首先讓我們看看如何在我們的測試中用FakeUserRepository替換UserRepository。

實現FakeUserRepository

FakeUserRepository是一個簡單的類，它為我們提供了假資料。它實現了UserRepository

介面。 DefaultUserRepository也實現了它，但它為我們提供應用程式中的真實資料。

class FakeUserRepository : UserRepository {

    override fun getUsers(page: Int, forced: Boolean): Single<UserListModel> {
        val users = (1..10L).map {
            val number = (page - 1) * 10 + it
            User(it, "User $number", number * 100, "")
        }

        return Single.create<UserListModel> { emitter: SingleEmitter<UserListModel> ->
            val userListModel = UserListModel(users)
            emitter.onSuccess(userListModel)
        }
    }
}

我認為這個程式碼不需要太多的解釋。我們建立了一個Single來發送一串假的users資料。雖然值得一提的是這部分程式碼：

val users = (1..10L).map

我們可以使用map函式從一個範圍裡建立列表。這在這種情況下可能非常有用。

注‘Android技術交流群878873098，歡迎大家加入交流，暢談！本群有免費學習資料視訊’並且免費分享原始碼解析視訊

將FakeUserRepository注入我們的測試

現在我們有了假的UserRepository實現，但我們如何在我們的測試中使用它呢？當使用Dagger時，我們通常有一個ApplicationComponent和一個ApplicationModule來提供應用程式級的依賴關係。我們在自定義Application類中初始化component。

class CustomApplication : Application() {

    lateinit var component: ApplicationComponent

    override fun onCreate() {
        super.onCreate()

        initAppComponent()

        Stetho.initializeWithDefaults(this);
        component.inject(this)
    }

    private fun initAppComponent() {
        component = DaggerApplicationComponent
                .builder()
                .applicationModule(ApplicationModule(this))
                .build()
    }
}

現在我們將建立一個FakeApplicationModule和一個FakeApplicationComponent，這將為我們提供FakeUserRepository。在我們的UI測試中，我們將component欄位設定為FakeApplicationComponent。

來看一下這個例子：

@Singleton
@Component(modules = arrayOf(FakeApplicationModule::class))
interface FakeApplicationComponent : ApplicationComponent

由於該component繼承自ApplicationComponent，所以我們可以使用它來替代。

@Module
class FakeApplicationModule {

    @Provides
    @Singleton
    fun provideUserRepository() : UserRepository {
        return FakeUserRepository()
    }

    @Provides
    @Singleton
    fun provideSchedulerProvider() : SchedulerProvider = AppSchedulerProvider()
}

我們不需要在這裡提供任何其他東西，因為大多數提供的依賴關係用於真正的UserRepository實現。

@RunWith(AndroidJUnit4::class)
class MainActivityTest {

    @Rule @JvmField
    var activityRule = ActivityTestRule(MainActivity::class.java, true, false)

    @Before
    fun setUp() {
        val instrumentation = InstrumentationRegistry.getInstrumentation()
        val app = instrumentation.targetContext.applicationContext as CustomApplication

        val testComponent = DaggerFakeApplicationComponent.builder()
                .fakeApplicationModule(FakeApplicationModule())
                .build()
        app.component = testComponent

        activityRule.launchActivity(Intent())
    }

    @Test
    fun testRecyclerViewShowingCorrectItems() {
        // TODO
    }
}
view raw

前兩個片段已經在上面解釋過了。這裡有趣的部分是MainActivityTest類。來看看這裡發生了什麼。

在setUp方法中，我們得到了一個CustomApplication類的例項，建立了我們的FakeApplicationComponent，接著啟動了MainActivity。

在設定component後，啟動Activity很重要。可以通過將另一個建構函式引數傳遞給ActivityTestRule的建構函式來實現。第三個引數是一個布林值，它決定了測試執行程式是否應立即啟動該Activity。

Espresso示例

現在我們可以開始寫一些測試。我不想過多描述如何用Espresso來編寫測試用例的細節，已經有了很多教程，但是我們先來看一個簡單的例子。

首先我們需要新增依賴關係到build.gradle。如果我們使用了RecyclerView，在普通espresso-core之外，我們還需要新增espresso-contrib依賴。

androidTestImplementation ('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })

    androidTestImplementation('com.android.support.test.espresso:espresso-contrib:2.2') {
        // Necessary to avoid version conflicts
        exclude group: 'com.android.support', module: 'appcompat'
        exclude group: 'com.android.support', module: 'support-v4'
        exclude group: 'com.android.support', module: 'support-annotations'
        exclude module: 'recyclerview-v7'
    }

現在我們的測試看起來是這樣：

@Test
fun testOpenDetailsOnItemClick() {
    Espresso.onView(ViewMatchers.withId(R.id.recyclerView))
            .perform(RecyclerViewActions.actionOnItemAtPosition<RecyclerView.ViewHolder>(0, ViewActions.click()))

    val expectedText = "User 1: 100 pts"

    Espresso.onView(Matchers.allOf(ViewMatchers.withId(android.support.design.R.id.snackbar_text), ViewMatchers.withText(expectedText)))
            .check(ViewAssertions.matches(ViewMatchers.isDisplayed()));
}

發生了什麼？

首先，我們找到RecyclerView然後在RecyclerViewActions的幫助下，點選它的第一個（0索引）項。

在我們作出斷言之後，一個Snackbar顯示出了User 1: 100 pts的文字。

這是一個非常簡單的測試用例。您可以在Github倉庫中找到更多測試用例的示例。該部分的程式碼更改可以在此提交中找到：

https://github.com/kozmi55/Kotlin-MVP-Testing/commit/8152c2065af2e0871ba1175cadecb92b3fa8417f

在UI測試中模擬UserRepository

如果我們想測試以下情景，該怎麼辦？

載入第一頁資料成功
載入第二頁錯誤
驗證當我們嘗試載入第二頁時是否在螢幕上顯示了Toast

我們不能在這裡使用我們的假實現，因為它總是成功返回一個user list。我們可以修改實現，對於第二個頁面，讓它返回一個會發送錯誤的Single，但這並不好。如果我們要新增另一個測試用例，我們需要一次又一次地進行修改。

注‘Android技術交流群878873098，歡迎大家加入交流，暢談！本群有免費學習資料視訊’並且免費分享原始碼解析視訊

這種情況我們可以模擬getUsers方法的行為。為此，我們需要對FakeApplicationModule進行一些修改。

@Module
class FakeApplicationModule(val userRepository: UserRepository) {

    @Provides
    @Singleton
    fun provideUserRepository() : UserRepository {
        return userRepository
    }
  
  ...
}

現在我們在建構函式中傳遞UserRepository，所以在測試中，我們可以建立一個mock物件，並使用它來構建我們的component。

@RunWith(AndroidJUnit4::class)
class MainActivityTest {

    ...

    private lateinit var mockUserRepository: UserRepository

    @Before
    fun setUp() {
        mockUserRepository = mock()

        val instrumentation = InstrumentationRegistry.getInstrumentation()
        val app = instrumentation.targetContext.applicationContext as CustomApplication

        val testComponent = DaggerFakeApplicationComponent.builder()
                .fakeApplicationModule(FakeApplicationModule(mockUserRepository))
                .build()
        app.component = testComponent
    }
  
  ...
}

這是我們修改後的測試類。使用了我在第一部分中提到過的用來模擬UserRepository的mockito-kotlin庫。我們需要新增以下依賴關係到build.gradle，然後使用它。

androidTestImplementation "com.nhaarman:mockito-kotlin-kt1.1:1.5.0"
androidTestImplementation 'com.linkedin.dexmaker:dexmaker-mockito:2.2.0'

現在我們可以修改模擬的行為了。我為此建立了兩個私有的工具方法，可以在測試用例中重用它們。

private fun mockRepoUsers(page: Int) {
    val users = (1..20L).map {
        val number = (page - 1) * 20 + it
        User(it, "User $number", number * 100, "")
    }

    val mockSingle = Single.create<UserListModel> { emitter: SingleEmitter<UserListModel> ->
        val userListModel = UserListModel(users)
        emitter.onSuccess(userListModel)
    }

    whenever(mockUserRepository.getUsers(page, false)).thenReturn(mockSingle)
}

private fun mockRepoError(page: Int) {
    val mockSingle = Single.create<UserListModel> { emitter: SingleEmitter<UserListModel> ->
        emitter.onError(Throwable("Error"))
    }

    whenever(mockUserRepository.getUsers(page, false)).thenReturn(mockSingle)
}

我們需要做的另一個改變是在建立模擬物件之後，在測試用例中啟動Activity，而不是在setUp方法中去啟動。

有了這個變化，我們前面的測試用例如下所示：

@Test
fun testOpenDetailsOnItemClick() {
    mockRepoUsers(1)

    activityRule.launchActivity(Intent())

    Espresso.onView(ViewMatchers.withId(R.id.recyclerView))
            .perform(RecyclerViewActions.actionOnItemAtPosition<RecyclerView.ViewHolder>(0, ViewActions.click()))

    val expectedText = "User 1: 100 pts"

    Espresso.onView(Matchers.allOf(ViewMatchers.withId(android.support.design.R.id.snackbar_text), ViewMatchers.withText(expectedText)))
            .check(ViewAssertions.matches(ViewMatchers.isDisplayed()));
}

GitHub倉庫中還有一些其它的測試用例，包括錯誤時的情況。此部分中的更改可以在此提交中看到：

https://github.com/kozmi55/Kotlin-MVP-Testing/commit/3889286528ad5a88035358894fda9e0be8c145aa

附贈：在Android測試中模擬final類

在Kotlin裡，預設情況下每個class都是final的，這使得mock變得複雜。在第一部分中，我們看到了如何用Mockito模擬final類。

不幸的是，這種方法在Android真機測試中不起作用。在這種情況下，我們有幾種解決方案，其中之一是使用Kotlin all-open 外掛。

這是一個編譯器外掛，它允許我們建立一個註解，如果使用它，將會開啟該類。

要使用它，我們需要新增以下依賴關係到我們專案(project)的build.gradle檔案：

classpath "org.jetbrains.kotlin:kotlin-allopen:$kotlin_version"

然後新增以下的內容到app模組的build.gradle檔案中:

apply plugin: 'kotlin-allopen'
allOpen {
    annotation("com.myapp.OpenClass")
}

現在我們只需要在我們指定的包中建立我們的註解：

@Target(AnnotationTarget.CLASS)
annotation class OpenClass

all-open外掛的示例可以在此提交中找到：

https://github.com/kozmi55/Kotlin-MVP-Testing/commit/8152c2065af2e0871ba1175cadecb92b3fa8417f

——————

我們到達了漫長的旅程的盡頭，覆蓋了我們應用程式中的每一個程式碼，並附帶了測試。感謝您閱讀這篇文章，希望您能發現這些文章是有用的。

Thanks for reading my article.

注‘Android技術交流群878873098，歡迎大家加入交流，暢談！本群有免費學習資料視訊’並且免費分享原始碼解析視訊

作者：ditclear
連結：https://www.jianshu.com/p/f56d8d1ce980
來源：簡書

【譯】使用Kotlin和RxJava測試MVP架構的完整示例 - 第3部分

【譯】使用Kotlin和RxJava測試MVP架構的完整示例 - 第3部分

【譯】使用Kotlin和RxJava測試MVP架構的完整示例 - 第2部分

【譯】使用Kotlin和RxJava測試MVP架構的完整示例 - 第1部分

(譯)使用Kotlin和RxJava處理複雜的請求

【譯】Go和WebAssembly：在瀏覽器中執行Go程式

【譯】XMLHttpRequest和Fetch, 誰最適合AJAX？

【譯】你不知道的Chrome除錯工具技巧第四天：the Elements panel（元素面板）

【譯】你不知道的Chrome除錯工具技巧第五天：console的log中,讓人疑惑的案例

【譯】你不知道的Chrome除錯工具技巧第七天：非同步consle的趣味小竅門

【譯】你不知道的 Chrome 除錯工具技巧第九天：給 console 計時

【譯】你不知道的 Chrome 除錯工具技巧第十一天：style editors continued（樣式編輯器後續）

【譯】你不知道的 Chrome 除錯工具技巧第十二天：忍者日誌列印！(the ninja logs)

【譯】你不知道的 Chrome 除錯工具技巧第十四天：其他快捷鍵~

【譯】你不知道的 Chrome 除錯工具技巧第十三天：物件 & 方法

【譯】你不知道的 Chrome 除錯工具技巧第十六天：斷點

【譯】微軟出品HashiCorp Terraform 和 Vault 系列視頻

【譯】理解 Javascript 執行上下文和執行棧

【轉】關於java 單元測試Junit4和Mock的一些總結

【譯】JavaScript的工作原理：引擎，執行時和呼叫堆疊的概述

【譯】Javascript: call()、apply() 和 bind()

【譯】使用Kotlin和RxJava測試MVP架構的完整示例 - 第3部分

相關推薦