之前幾天的文章都在介紹Espresso的寫法，當我們都寫好了以後開始想利用CI/CD做一些事的時候需要先理解一些關於Android的測試架，Gradle Script及模擬器emulator的設定。

Android在發起Instrumentation Test的時候會產生Production APK跟Test APK，再驅動Test APK裡的test script去執行Proudction APK用以達到驗證的目的。而在多個Test case狀況下必須透過Orchestrator的幫助來成test suite裡所有test cases。

Animation off

Animation在做Espresso的時候有一個大問題就是Testing thread不會等到動畫結束才往下執行使得測試失敗，也就是View還在執行Animation的時候，Espresso已經針對View在執行Assertion判斷，如同callback還沒結束espresso就在判斷callback內容當然會錯。因為動畫的效果在測試的環節並不是重點，因此在做Instrumentation Test要先進Developer Options把動畫關掉off。

當然你想如果直接關掉動畫那我測試完畢後想看動畫不是又要手動打開很不方便，這裡建議可以使用3rd party library，在build.gradle的buildscript中加入novoda的library。

buildscript {
    dependencies {
        classpath 'com.novoda:gradle-android-command-plugin:2.1.0'
    }
}

然後在build.gradle的android目錄下加入afterEvaluate的區塊。

    afterEvaluate {
        if (tasks.findByPath("connectedAndroidTest") != null) {
            connectedAndroidTest.dependsOn disableSystemAnimations
            connectedAndroidTest.finalizedBy enableSystemAnimations
        }
    }

connectedAndroidTest是android預設的instrumentation test的指令，我們可以在command line輸入
./graldw connectedAndroidTest這樣就會執行所有我們放在androidTest資料夾下的instrumentation test。而afterEvaluate區塊內的disableSystemAnimations及enableSystemAnimations就是幫我們在connectedAndroidTest的前後打開及關閉動畫設定的部份，而這個方式在我執行remote automation也必須用到，因為emulator都是runtime產生的。

設定ORCHESTRATOR

之前提過如果今天我們寫了很多test case想要一起執行的話，必須使用orchestrator來幫忙清除resource及重新setup環境，怎麼說呢？我們知道每個test的執行環境應該都要獨立，也就是test A的操作不能影響test B的操作，所以在每個test function執行時所有的條件都要重新來過，例如MainActivity都要重新launch而不是用剛剛launch的實體繼續使用。但是Android在Intrumentation Test時沒有這個能力幫你做到在每個test case重新setup，除非加入orchestrator的dependency如下。

    androidTestUtil 'androidx.test:orchestrator:1.2.0'

加入dependency後我們還要在build.gradle的android的目錄下加入testOptions的使用。這樣我們就有能力一次執行一堆instrumentation test了。

    testOptions {        
        execution 'ANDROIDX_TEST_ORCHESTRATOR'
    }

Build Variant

剛剛有提到Android預設的instrumentation test的command line是./gradlew connectedAndroidTest，這個執行方式是無差別執行，會把所有gradle裡設定的build variant通通跑一遍。比較好的方式是針對不同的測試環境設定不同的條件build variant，再針對這些條件下去跑test。
我們通常依不同開發需求會在build.gradle裡的android目錄下設定productFlavors和buildTypes，再由這個組合去build不同條件的apk，例如server的連線不同。
因此我們instrumentation test的指令可以依build的不同把connectedAndroidTest改成connectedDebugAndroidTest或是connectedStagingDebugAndroidTest，我們來看怎麼設定build variant

productFlavors {
        staging {
            applicationId "com.daniel.demotest.staging"
        }
        
        production {
            applicationId "com.daniel.demotest"
        }
    }
    
buildTypes {
        release {   
        }

        debug {      
        }
    }

介紹完一些執行Instrumentation Test的設定後，下一步我們就來試試看能不能架一個Jenkins並且trigger automation testing在上面。