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

時間  2019-11-21
標籤 使用 kotlin rxjava 測試 mvp 架構 完整 示例 部分 欄目 Java 简体版
原文   原文鏈接

原文連接：android.jlelse.eu/complete-ex…java

簡書譯文地址:www.jianshu.com/p/0a845ae2c…android

這是關於測試Kotlin中MVP應用程序每一層的文章的第二部分。 在第一部分，咱們討論了模型層(Model)和交互層(Interactor)的測試。 若是你錯過了，你能夠在這裏查看。

android.jlelse.eu/complete-ex…git

在這部分中，我將向您展現如何使用RxJavaPlugins和依賴注入替代使用 test schedulers來測試presenter。 咱們還將看到如何在咱們的測試中控制schedulers的時間。github

測試UserListPresenter

UserListPresenter的代碼很簡單。 它只有兩個公共方法。app

  • getUsers - 從交互層請求用戶，並根據結果更新UI。
  • onScrollChanged - 處理RecyclerView的滾動變化。 若是咱們到達列表中的特定元素，咱們已經開始在後臺獲取下一頁 數據，而且僅在用戶到達最後一個元素時顯示加載指示符，此時加載還未完成。
class UserListPresenter(
        private val getUsers: GetUsers) : BasePresenter<UserListView>() {

    private val offset = 5

    private var page = 1
    private var loading = false

    fun getUsers(forced: Boolean = false) {
        loading = true
        val pageToRequest = if (forced) 1 else page
        getUsers.execute(pageToRequest, forced)
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(
                        { users -> handleSuccess(forced, users) }, 
                        { handleError() })
    }

    private fun handleSuccess(forced: Boolean, users: List<UserViewModel>) {
        loading = false
        if (forced) {
            page = 1
        }
        if (page == 1) {
            view?.clearList()
            view?.hideEmptyListError()
        }
        view?.addUsersToList(users)
        view?.hideLoading()
        page++
    }

    private fun handleError() {
        loading = false
        view?.hideLoading()
        if (page == 1) {
            view?.showEmptyListError()
        } else {
            view?.showToastError()
        }
    }

    fun onScrollChanged(lastVisibleItemPosition: Int, totalItemCount: Int) {
        val shouldGetNextPage = !loading && lastVisibleItemPosition >= totalItemCount - offset
        if (shouldGetNextPage) {
            getUsers()
        }

        if (loading && lastVisibleItemPosition >= totalItemCount) {
            view?.showLoading()
        }
    }
}複製代碼

UserListPresenter.kt hosted with ❤ by GitHub框架

使用即時調度器覆蓋默認的RxJava調度器

首先，咱們將看到如何使用一個能夠在RxJavaPlugins的幫助下當即運行命令的scheduler替換RxJava schedulers。ide

RxJavaPlugins是一個實用的類，它容許咱們修改RxJava的默認行爲。 咱們只須要更改默認的scheduler，就能夠改變關於RxJava如何工做的其餘幾個方面。函數

首先讓咱們爲UserListPresenter寫一個簡單的測試，看看會發生什麼。工具

class UserListPresenterTest {

    @Mock
    lateinit var mockGetUsers: GetUsers

    @Mock
    lateinit var mockView: UserListView

    lateinit var userListPresenter: UserListPresenter

    @Before
    fun setUp() {
        MockitoAnnotations.initMocks(this)
        userListPresenter = UserListPresenter(mockGetUsers)
    }

    @Test
    fun testGetUsers_errorCase_showError() {
        // Given
        val error = "Test error"
        val single: Single<List<UserViewModel>> = Single.create {
            emitter ->
            emitter.onError(Exception(error))
        }

        // When
        whenever(mockGetUsers.execute(anyInt(), anyBoolean())).thenReturn(single)

        userListPresenter.attachView(mockView)
        userListPresenter.getUsers()

        // Then
        verify(mockView).hideLoading()
        verify(mockView).showEmptyListError()
    }
}複製代碼

若是你已經閱讀了第一部分，那這裏應該沒有什麼新鮮事。 咱們使用Mockito建立一些模擬對象，在UserListPresenter上調用一些方法，而後驗證預期的行爲。oop

可是，若是咱們嘗試運行此測試，咱們將面臨如下錯誤：

java.lang.ExceptionInInitializerError
...
Caused by: java.lang.RuntimeException: Method getMainLooper in android.os.Looper not mocked. See http://g.co/androidstudio/not-mocked for details.
 at android.os.Looper.getMainLooper(Looper.java)複製代碼

這是由於AndroidSchecdulers.mainThread（）和Android框架的依賴關係，然而咱們正在建立本地的單元測試。

在這裏，咱們可使用RxJavaPlugins和RxAndroidPlugins這些類來覆蓋默認的scheduler。

首先咱們在測試類中建立一個immediateScheduler字段。 咱們必須從RxJava擴展Scheduler類，並覆蓋createWorker方法以當即運行操做。 而後在setUp方法中，咱們調用RxJavaPlugins和RxAndroidPlugins的靜態方法來覆蓋調度器。 下面的代碼段實現了這一點。 咱們還須要在tearDown方法中重置調度器。

class UserListPresenterTest {

    private val immediateScheduler = object : Scheduler() {
        override fun createWorker(): Worker {
            return ExecutorScheduler.ExecutorWorker(Executor { it.run() })
        }
    }
    ...

    @Before
    fun setUp() {
        ...
        RxJavaPlugins.setInitIoSchedulerHandler { immediateScheduler }
        RxAndroidPlugins.setInitMainThreadSchedulerHandler { immediateScheduler }
        ...
    }

    @After
    fun tearDown() {
        RxJavaPlugins.reset()
        RxAndroidPlugins.reset()
    }
}複製代碼

如今咱們的測試將會經過。這裏咱們只覆蓋了兩個調度器，可是在RxJava中還有更多的調度器。 因爲咱們在UserListPresenter中只使用這兩個，因此沒有必要重寫其他的。

這很棒，可是若是咱們有10個presenter，難道咱們須要在全部的測試中去作這些？ 固然不是。 咱們能夠建立一個TestRule，在那裏咱們覆蓋scheduler，並將它應用在咱們須要的每一個測試中。

class ImmediateSchedulerRule : TestRule {
    private val immediate = object : Scheduler() {
        override fun createWorker(): Worker {
            return ExecutorScheduler.ExecutorWorker(Executor { it.run() })
        }
    }

    override fun apply(base: Statement, d: Description): Statement {
        return object : Statement() {
            @Throws(Throwable::class)
            override fun evaluate() {
                RxJavaPlugins.setInitIoSchedulerHandler { immediate }
                RxJavaPlugins.setInitComputationSchedulerHandler { immediate }
                RxJavaPlugins.setInitNewThreadSchedulerHandler { immediate }
                RxJavaPlugins.setInitSingleSchedulerHandler { immediate }
                RxAndroidPlugins.setInitMainThreadSchedulerHandler { immediate }

                try {
                    base.evaluate()
                } finally {
                    RxJavaPlugins.reset()
                    RxAndroidPlugins.reset()
                }
            }
        }
    }
}複製代碼

在 TestRule中，咱們覆蓋每一個scheduler，因此若是咱們使用其餘scheduler，咱們能夠在任何地方使用相同的TestRule。 若是咱們從未在咱們的應用程序中使用特定的scheduler，咱們能夠將其從TestRule中排除。

要使用咱們新建立的TestRule，咱們須要將如下代碼添加到咱們的測試類中。

@Rule @JvmField
val immediateSchedulerRule = ImmediateSchedulerRule()複製代碼

咱們須要添加@JvmField註釋，由於@Rule註釋僅適用於字段和getter方法，但immediateSchedulerRule是Kotlin中的一個屬性。

就這樣，如今咱們可使用immediate scheduler來測試咱們的presenter。 變動能夠在此提交中找到（它還包含一些測試用例，這裏沒有顯示）：

github.com/kozmi55/Kot…

使用TestScheduler來控制時間

在大多數狀況下，immediate scheduler就足夠了。 但有時咱們須要控制時間來測試某些功能。 看看UserListPresenter中的onScrollChanged方法， 你會怎樣測試？ loading字段將始終爲false，由於getUsers會當即執行。 咱們能夠將該字段設置爲公共的，但僅由於測試就暴露一個字段是很差的作法。

RxJava爲這些狀況提供了一個名爲TestScheduler類。 這是一個特殊的scheduler，它容許咱們手動的將一個虛擬時間提早。 一個簡單的例子：

@Test
fun testOnScrollChanged_offsetReachedAndLoading_dontRequestNextPage() {
    // Given
    val users = listOf(UserViewModel(1, "Name", 1000, ""))
    val single: Single<List<UserViewModel>> = Single.create {
        emitter ->
        emitter.onSuccess(users)
    }

    val delayedSingle = single.delay(2, TimeUnit.SECONDS, testScheduler)

    // When
    whenever(mockGetUsers.execute(anyInt(), anyBoolean())).thenReturn(delayedSingle)

    userListPresenter.attachView(mockView)
    userListPresenter.getUsers()

    testScheduler.advanceTimeBy(1, TimeUnit.SECONDS)

    userListPresenter.onScrollChanged(5, 10)

    // Then
    verify(mockGetUsers, times(1))
            .execute(ArgumentMatchers.anyInt(), ArgumentMatchers.anyBoolean())
}複製代碼

使用delay方法，咱們能夠建立一個不能當即完成的Single。 該方法的第三個參數是Scheduler。 若是咱們傳遞一個TestScheduler實例，那這2秒將是虛擬的。 如今咱們可使用TestScheduler的方法來改變這個虛擬時間。 這能夠在示例的第18行中看到。

在咱們的例子中，咱們有一個須要2秒鐘的時間才能完成的Single，而咱們提早了1秒鐘。 因此當咱們向下滾動時，mockGetUsers.execute不會再被調用一次，由於第一個調用仍然加載，所以咱們應該驗證，該方法將被調用一次。

TestScheduler還有一個advanceTimeTo方法，它將時間移動到特定的時刻。

注入TestScheduler

咱們一樣能夠用TestScheduler替換默認的scheduler，這是咱們前面使用的，可是因爲某種緣由，它給我一個奇怪的錯誤。 當我一次運行整個測試類時，只有第一個測試經過，其他的測試一般會失敗，由於沒有觸發動做（我使用TestScheduler.triggerAction方法進行更簡單的測試，在那裏我不須要控制時間）。 爲了解決這個問題，即便咱們不須要控制時間，也須要使用advanceTimeBy方法來代替triggerAction。

雖然這個解決方案是有效的，可是這使我意識到，替換scheduler的方法還能更簡潔，那就是依賴注入。

首先要作到這一點，咱們須要建立一個SchedulerProvider接口，並提供兩個實現。

  • AppSchedulerProvider - 這將爲咱們提供真正的調度器。 咱們將把這個類注入全部的presenter，這將爲咱們的Rx訂閱提供調度器。
  • TestSchedulerProvide - 這個類將爲咱們提供一個TestScheduler而不是真正的scheduler。 當咱們在測試中實例化咱們的presenter時，咱們將使用它做爲它的構造函數參數。
interface SchedulerProvider {
    fun uiScheduler() : Scheduler
    fun ioScheduler() : Scheduler
}

class AppSchedulerProvider : SchedulerProvider {
    override fun ioScheduler() = Schedulers.io()
    override fun uiScheduler(): Scheduler = AndroidSchedulers.mainThread()
}

class TestSchedulerProvider() : SchedulerProvider {

    val testScheduler: TestScheduler = TestScheduler()

    override fun uiScheduler() = testScheduler
    override fun ioScheduler() = testScheduler
}複製代碼

爲了簡單起見，我將這3個類添加到同一個要點，但在項目中它們是在一個單獨的文件中。

如今咱們須要在UserListPresenter中添加SchedulerProvider做爲構造函數參數，並將如下行

.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())複製代碼

改成這些：

.subscribeOn(schedulerProvider.ioScheduler())
.observeOn(schedulerProvider.uiScheduler())複製代碼

咱們還須要在咱們的ApplicationModule中添加一個provider方法，以提供SchedulerProvider依賴關係。

@Provides
@Singleton
fun provideSchedulerProvider() : SchedulerProvider = AppSchedulerProvider()複製代碼

如今咱們能夠在咱們的測試中使用TestSchedulerProvider,以下所示：

@Mock
    lateinit var mockGetUsers: GetUsers

    @Mock
    lateinit var mockView: UserListView

    lateinit var userListPresenter: UserListPresenter

    lateinit var testSchedulerProvider: TestSchedulerProvider

    @Before
    fun setUp() {
        MockitoAnnotations.initMocks(this)
        testSchedulerProvider = TestSchedulerProvider()
        userListPresenter = UserListPresenter(mockGetUsers, testSchedulerProvider)
    }

  ...
  // Test methods
}複製代碼

若是咱們要在測試中使用TestScheduler，咱們須要獲得提供者的這一屬性：testSchedulerProvider.testScheduler

就這些。 您能夠在庫裏找到更多關於如何處理時間的測試用例。 我建立了一些私有的工具方法來提取這些測試的常見部分，並使代碼更簡潔。 您能夠在此提交中找到它：

github.com/kozmi55/Kot…

···

感謝您閱讀本系列的第二部分。 咱們介紹瞭如何使用RxJava來測試presenter，並學習了在測試中處理RxJava scheduler的不一樣技巧。

在最後一部分，咱們將看到如何使用Espresso進行假數據的UI測試，以及如何處理Espresso測試中某些Kotlin的特定問題。

Thanks for reading my article.

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程