原文链接：https://android.jlelse.eu/complete-example-of-testing-mvp-architecture-with-kotlin-and-rxjava-part-2-ca150c688ab1

这是关于测试Kotlin中MVP应用程序每一层的文章的第二部分。 在第一部分，我们讨论了模型层(Model)和交互层(Interactor)的测试。 如果你错过了，你可以在这里查看。

https://android.jlelse.eu/complete-example-of-testing-mvp-architecture-with-kotlin-and-rxjava-part-1-816e22e71ff4

在这部分中，我将向您展示如何使用RxJavaPlugins和依赖注入替代使用 test schedulers来测试presenter。 我们还将看到如何在我们的测试中控制schedulers的时间。

测试UserListPresenter

UserListPresenter的代码很简单。 它只有两个公共方法。

• 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。

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上调用一些方法，然后验证预期的行为。

但是，如果我们尝试运行此测试，我们将面临以下错误：

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。 变更可以在此提交中找到（它还包含一些测试用例，这里没有显示）：

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

使用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

就这些。 您可以在库里找到更多关于如何处理时间的测试用例。 我创建了一些私有的工具方法来提取这些测试的常见部分，并使代码更简洁。 您可以在此提交中找到它：

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

···

感谢您阅读本系列的第二部分。 我们介绍了如何使用RxJava来测试presenter，并学习了在测试中处理RxJava scheduler的不同技巧。

在最后一部分，我们将看到如何使用Espresso进行假数据的UI测试，以及如何处理Espresso测试中某些Kotlin的特定问题。

Thanks for reading my article.