原文連結:android.jlelse.eu/complete-ex…
簡書譯文地址:www.jianshu.com/p/0a845ae2c…
這是關於測試Kotlin中MVP應用程式每一層的文章的第二部分。 在第一部分,我們討論了模型層(Model)和互動層(Interactor)的測試。 如果你錯過了,你可以在這裡檢視。android.jlelse.eu/complete-ex…
在這部分中,我將向您展示如何使用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。 變更可以在此提交中找到(它還包含一些測試用例,這裡沒有顯示):
使用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
就這些。 您可以在庫裡找到更多關於如何處理時間的測試用例。 我建立了一些私有的工具方法來提取這些測試的常見部分,並使程式碼更簡潔。 您可以在此提交中找到它:
···
感謝您閱讀本系列的第二部分。 我們介紹瞭如何使用RxJava來測試presenter,並學習了在測試中處理RxJava scheduler的不同技巧。
在最後一部分,我們將看到如何使用Espresso進行假資料的UI測試,以及如何處理Espresso測試中某些Kotlin的特定問題。
Thanks for reading my article.