在剛開始接觸 IdlingResource 的時候,對它抱有太多的幻想,以為可以肆無忌憚的處理異步的問題,使用之后才發現問題其實也不少,甚至還有一些明顯的 bug。
在 IdlingResource 的說明文檔里說可以總結成這樣一句話 you have to use Idling Resources to inform Espresso of the app’s long-running operations.
。在這里我們并不能很直白的理解出 IdlingResource 只能用來等待 UI events
。也就是說在官方的設計里面,要使用 IdlingResource 來維持對應的后臺操作,后面的緊跟著一條 UI 操作或驗證,否則將不會生效。這樣導致的結果是在一個后臺操作完成以后是關閉當前頁面的場景,根本無法測試。
如果這算是 Espresso 的特性的話,下面這個就是一個明顯的 bug。
在進行 UI 測試的時候,有兩個主線程需要區分一下,一個是主 App 運行的主線程([main,5,main]),另一個是 UI 測試跑的主線程([Instr: android.support.test.runner.AndroidJUnitRunner,5,main])。我們觸發的UI事件都是在 App 主線程里面執行的,如果我們想要在 App 的線程里面做一些操作需要切換到對應的線程操作。如下面的代碼:
1
2
3
4
5
6
7
8
9
10
11
12
|
mActivityTestRule.getActivity().runOnUiThread(new Runnable() {
@Override
public void run() {
LogUtils.d(TAG, "runOnUiThread..." + Thread.currentThread());
TaskApi.Companion.getMyTasks(0, 10000, "", new HSAPICallback<TaskListResult>() {
public void onRequestSuccess(TaskListResult data, int httpStatus,Boolean fromCache) {
super.onRequestSuccess(data, httpStatus, fromCache);
mTasks = data.getDatas();
}
});
}
});
|
原文轉自:http://ohmerhe.com/2017/04/18/espresso_huge_ui_test/