【译】使用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教程