如何正確使用Espresso來測試你的Android程序

UI測試在Android平台上一直都是一個令人頭痛的事情, 由於大家平時用的很少, 加之很多文檔的缺失, 如果很多東西從頭摸索,勢必踩坑無數.

自Android24正式淘汰掉了InstrumentationTestCase(位於android.test包), 推出Espresso(位於android.support.test包), Google一直致力於降低UI測試的門檻.

了解測試金字塔的同學可能知道,UI測試屬於功能測試(Functional Test), 或者按照其他的划分也屬於集成測試(Integration Test), Google推出了UIAutomator與Espresso來分別處理跨App間的測試(黑盒測試)以及App內的測試(白盒測試).

測試步驟類似,分為:

• 查找元素
• 觸發行為
• 檢測結果

本文分為三部分, 第一部分簡單介紹如何使用Espresso, 第二部分分析如何處理諸如異步, 依賴注入, 程序結構對UI測試的影響以及提供解決辦法, 第三部分提供源碼以及一些Reference的地址.

Part I

如何配置

1.需要在gradle的dependencies里添加依賴

androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test:rules:1.0.2'

2.在gradle的android.defaultConfig里指定TestRunner

testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"

3.書寫測試文件,通過AndroidJUnit4來跑即可,使用Activity Rule來啟動你的Activity.

@Rule
@JvmField
var activityTestRule: ActivityTestRule<MainActivity> = ActivityTestRule<MainActivity>()

4.添加測試.

onView(withText("Hello world!")).check(matches(isDisplayed()));

5.運行

./gradlew connectedAndroidTest

或在IDE中進行運行.

以上步驟寫的比較簡略, 如果第一次使用, 可參考官方文檔.

Part II

貌似已經會了, 打鈎[x]?

對於簡單的UI其實上面的5步已經完全足夠, 這也是Espresso好用的地方, 將UI測試寫的跟普通的Unit Test一樣簡單.

但是隨着你的UI變得復雜, 很多問題接踵而至.

其根本原因在於, Espresso系統在處理內置UI渲染(包括WebView)的異步操作都沒有問題, 它會等待頁面的渲染與加載, 而你自己如果有異步邏輯, 可能測試進程不會等待其完成而結束, 導致測試失敗.

而采用Unit Test將無論是RxJava的Scheduler或者是Excutor替換成同一個線程的方法沒法在UI Test中使用. 原因是UI操作只能在創建它的線程使用(UI 線程), 而如果你用了網絡或者Room之類的數據庫, 它又無法在UI線程使用, 相互矛盾, 進退兩難.

所以這個時候就需要使用Espresso提供的IdleResource, 來通知系統是否Idle或者Busy.

什么時候該使用IdleResource

其實IdleResource的官方文檔里面有指出, 如果你的測試里有使用:

• Thread.sleep()
• Retry
• CountDown ...

來保證你的測試工作正常, 那么意味着你應該使用IdleResource了.

或許剛剛接觸Espresso的你可能還沒有意識到問題所在, 還沒有使用Work Around的方法來解決問題, 換個角度來說可能更好理解.

如果你所測試程序里有使用:

• Databinding
• LiveData
• 通過非AsyncTask實現的異步操作
• Fragment跳轉
• 等等...

那么就意味着你需要使用IdleResource來保證你的測試能順利進行, 否則Test Case可能在程序異步操作未執行時就已經關閉了.

如何使用IdleResource

IdleResource的三個關鍵接口都非常Straigtforward.

1:

fun getName(): String

每一個IdleResource都應該有唯一的Name來注冊到系統里, 不能重復.

2:

fun isIdleNow(): Boolean

Espresso會從UI線程調用, 通過這個方法來獲得是否進入Idle狀態.

3:

fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback)

當該IdleResource被使用時, Espresso會注冊該callback, 當background job執行完畢后, 需要調用callback.onTransitionToIdle()通知(如果已經是Idle狀態, 調用也不影響, 所以很多簡單的實現都是將這個調用放在isIdleNow中, 判斷已經idle就調用, 雖然google的best practice里說不要這樣), 該調用會通知UI線程, 並可以在任何線程調用.

在使用IdleResource的時候, 通常是通過注冊Rule來驅動的, 這個就需要繼承TestWatcher.

復寫它的starting與finished方法, 通過IdlingRegistry.getInstance().register與IdlingRegistry.getInstance().unregister來注冊/反注冊IdleReource, 當然可能需要在finished的時候drain掉所有在運行的Task.

給一個簡單的例子把.

class SampleIdleResourceRule : TestWatcher() {
    private val idlingResource: IdlingResource = xxx
    
    override fun starting(description: Description?) {
        IdlingRegistry.getInstance().register(idlingResource)
        super.starting(description)
    }
    
    override fun finished(description: Description?) {
        //drain all the pending task here if needed.
        IdlingRegistry.getInstance().unregister(idlingResource)
        super.finished(description)
    }
}

舉個IdleResource的例子吧.

1.使用LiveData等Archtecture Component組件

我們知道LiveData是一個訂閱系統, 是必涉及后台線程, 比較方便的是它自己內部已經調用了IdleResource來增加/減少后台job, 所以直接使用系統提供的CountingTaskExecutorRule.

由於Resource name不能重復, 所以為了繞過這個檢測, 需要繼承CountingTaskExecutorRule來復寫getName.

具體可以參考google的TaskExecutorWithIdlingResourceRule.

Google還提供了Databinding的Rule, 可以參考.

2.等待彈框結束

一般情況下我們使用DialogFragment來彈框, 如果我們去check一些text被dialog遮擋, 就必須等待其消失后在進行檢查.

這時我們可以通過findFragmentByTag來檢測該彈框是否dismiss.

class DialogIdlingResource(
        private val manager: FragmentManager, 
        private val tag: String) : IdlingResource {
    private var resourceCallback: IdlingResource.ResourceCallback? = null

    override fun getName(): String = "xxx"

    override fun registerIdleTransitionCallback(callback: IdlingResource.ResourceCallback?) {
        resourceCallback = callback
    }

    override fun isIdleNow(): Boolean {
        val idle = manager.findFragmentByTag(tag) == null
        if (idle) {
            resourceCallback?.onTransitionToIdle()
        }
        return idle
    }
}

3.Delegate Executors/Scheduler

如果有異步處理邏輯, 大多都位於Repository/ViewModel層, 這部分會被Mock, 但也有一些UI邏輯可能會用到Excecutor. 如RecyclerView的DiffUtil, 需要傳入一個Executor來做異步Diff, 這時我們就需要一個Excecutor的IdlingResource, 並把它里面的Delegate賦值給UI.

這部分可以參考Google GithubBrowser Sample的CountingAppExecutorsRule.

應該怎么測試, 需要測試什么?

雖然Espresso測試是集成測試, 但是由於涉及到異步邏輯導致Test Case無法按照預期進行的問題時而存在, 且有時候無法通過IdlingResource來解決.

比如涉及到多個Fragment的跳轉, 就會發生在Fragment未打開時Test Case就掛掉的情況.

再比如使用RxJava, 在Espresso3.x + RxJava2.x的情況下, 即便將Scheduler代理給IdlingResource也無法保證整個業務流程完整走下來, 異步操作仍無法完整運行, 具體問題可參考Jake大神RxIdler的Issue.

所以測試起來就有一些原則需要遵守, 才能保證整個流程的可測性.

• 最好對每一個Fragment進行單獨測試, Mock所依賴的部分, 如網絡, 數據模塊, 如果涉及Fragment跳轉邏輯, 通過繼承來復寫進行測試.
• 如果使用了RxJava, 需要將其封裝在Repository或者Presenter/ViewModel中進行整體的Mock.
• 如果使用了Dagger2.android進行自動注入, 最好對測試部分自定義TestRunner提供一個空的Application來Disable注入, 對所測試Fragment注入對象進行手動賦值.
• 如果Activity有注入邏輯, 最好將其解耦到Fragment, 因為Espresso的Activity是通過ActivityRule來啟動, 無法進行直接手動注入.
• 如果無法Move到Fragment, 或者不想... 那就需要在測試里構建自己的Dagger Component, 對於使用Dagger2.android自動注入的, 還需要手動創建Fake的DispatchingAndroidInjector完成手動注入.
• 如果未使用Dagger2.android, 通過AndroidInjector來注入的, 可以忽略與注入相關的item.

能再講的仔細一些嗎?

1.單獨測試Fragment的好處是可以解耦Fragment之間的跳轉, 往往Fragment都是UI流程中的一個環節, 當邏輯完成時會跳向下一Fragment. 可以創建一個空Activity來專門用於顯示該Fragment, 並且在測試的setUp里commit該Fragment.

class TestActivity {
    fun showFragment()
}

@RunWith(AndroidJUnit4::class)
class XXXFragmentTest {
    @Rule
    @JvmField
    val activityRule = ActivityTestRule(XXXFragment::class.java)
    
    @Before
    fun init() {
        //1. init fragment
        //2. assign mock data
        activityRule.showFragment(xxx)  
    }
    
    @Test
    fun testXXX() {
        xxx
    }
}

2.由於常常會需要繼承需要測試的Fragment來復寫一些類, 對於使用Dagger.android自動注入的, 該子Fragment又未通過@ContributesAndroidInjector進行注冊, 往往需要自定義TestRunner, 然后手動注入Fragment.

class CustomTestRunner : AndroidJUnitRunner() {
    override fun newApplication(...) {
        return ...TestApp:class...
    }
}

android {
    defaultConfig {
        testInstrumentationRunner "xxx.CustomTestRunner"
    }
}

class TestApp : Application() {}

@RunWith(AndroidJUnit4::class)
class XXXFragmentTest {
    //activity rule
    ...
    val testFragment = TestFragment()
    
    @Before
    fun init() {
        testFragment.xxx = mockXXX
        ...
        activityRule.activity.showFragment(testFragment)
    }
    
    @Test
    fun testXXX() {
        onView...check(...)
        assertTrue(testFragment.isXXXShow)
    }
    
    class TestFragment : XXXFragment() {
        var isXXXShow = false
        override fun showXXX() {
            isXXXShow = true
        }
    }
}

3.如果Activity有注入邏輯與業務邏輯, 並且不想抽到Fragment中去, 則需要創建Fake的Injector保證可以完成注入,

fun createFakeInjector(block: T.() -> Unit): DispatchingAndroidInjector<Activity> {
    ...
}

@RunWith(AndroidJUnit4::class)
class XXXActivityTest {
    @Rule
    @JvmField
    var activityRule = object : ActivityTestRule<XXX>(XXX::class.java) {
       val app = ...get application
       app.dispatchingAndroidInjector = createFakeInjector<XXX>() {
           //手動注入
           xxx =  mockXXX
           `when`(xxx).thenReturn(xxx)
       }
    }
}

4.為了支持需要通過繼承Fragment來完成測試的Case, 還需要對測試模塊創建自己的Component來注冊從而進行Fake Injector的創建 (類似3, 只是Application/Activity可能為Test版本).

Grale

dependencies {
    kaptAndroidTest 'com.google.dagger:dagger-android-processor:2.X'
}


@Component(modules = [
    AndroidInjectionModule::class,
    AndroidSupportInjectionModule::class,
    ...主App所注冊的所有Module,
    TestActivityModule::class])
interface TestCompnent {
    fun inject(xxx: XXX)
    ...
}

@Module
abstract class TestActivityModule {
  //通過`ContributesAndroidInjector`注冊你的TestActivity, 以及TestFragment  
}

class TestApp : Application(), HasActivityInjector {
    @Inject
    lateinit var injector: DispatchingAndroidInjector<Activity>
}

class TestActivity : Activity(), HasSupportFragmentInjector {
    @Inject
    lateinit var injector: DispatchingAndroidInjector<Fragment>
}

Part III

如果還不是很明白可以查看代碼

Disable注入的在這里:
Google的Demo GithubBrowser

跟注入相關的在這里:
自己的Demo

Reference

• https://proandroiddev.com/activity-espresso-test-with-daggers-android-injector-82f3ee564aa4
• https://github.com/SabagRonen/dagger-activity-test-sample
• https://github.com/googlesamples/android-architecture-components/tree/master/GithubBrowserSample
• https://developer.android.com/training/testing/espresso/idling-resource
• http://blog.sqisland.com/2015/07/espresso-wait-for-dialog-to-dismiss.html

歡迎關注微信公眾號: 聖騎士Wind