Androidテスト導入入門 - Why don't you write a test ?

Why don't you write a test ?

Androidでユニットテストを書くまでの流れを雑にまとめた（2015/8/12時点）．

runner

Androidでいい感じにunit testingするためのライブラリにはRobolectricやTesting Support Libraryが有名．Testing Support Libraryは実機やEmulator上でテストを走らせるのに対し，RobolectricはDalvik/ARTじゃなく普通のJVMで走らせるので早い代わりに挙動が異なる可能性がある
．
今回は公式に提供されているTesting Support Libraryを利用する．
しかし，Robolectricの方がShadow Objectいっぱいあったりと高性能ではあるので状況次第．

android {
    // 省略

    defaultConfig {
        // 省略
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
    packagingOptions {
        exclude 'LICENSE.txt'
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/LICENSE.txt'
        exclude 'META-INF/NOTICE'
    }
    // 省略
}

dependencies {
    // 省略

    androidTestCompile 'com.android.support.test:runner:0.3'
    androidTestCompile 'com.android.support.test:rules:0.3'
}

これで以下のコマンドでテストが走るようになる（Android StudioからRunさせることも可能）．
要エミュレータ or 実機．

$ ./gradlew connectedAndroidTest

assertion

JUnit4におけるassertionではhamcrestがメジャーである（？）が，ここではよりクールにテストが書けるAssertJを利用する．
AssertJはRubyにおけるRSpecやJSにおけるJasmine，Mochaのようなインタフェースで利用でき，Spec形式のテストに慣れている人間には取っ付き易い．

しかし，AssertJの2系はJava 7，3系はJava 8が必須となりややこしい．
square社がAndroid用便利Matcher等を追加したAssertJ Androidを提供しており，Androidでも動作するよAssertJのバージョンも調整してくれているので，それを利用する．

dependencies {
    // 省略

    androidTestCompile 'com.squareup.assertj:assertj-android:1.0.1'
}

mock/stub/spy

mock/stub/spyにはMockitoおよびDexmakerを利用する．
finalなクラスのmock化をしたい場合などはPowerMockがあるが，どうもDexmakerと相性が悪いらしい（参考: java - How to get Powermock to work with Dexmaker - Stack Overflow）．

さらに，Dexmakerは最新版（1.4.0）だと正常に動作しないっぽいのでちょっと古いやつを利用する必要がある（参考: Unable to run tests with Android and 1.3 · Issue #18 · crittercism/dexmaker）．

dependencies {
    // 省略

    androidTestCompile 'org.mockito:mockito-core:1.9.5'
    androidTestCompile 'com.google.dexmaker:dexmaker:1.2'
    androidTestCompile 'com.google.dexmaker:dexmaker-mockito:1.2'
}

AndroidのAPIにあるfinalクラスをMockにしたい場合とかはおとなしくRobolectric使ったほうがいいかもしれない．

CI

Circle CIやTravis CIなど種類は色々あるけど，ここではWerckerを利用する．
ここでは割愛するが，例えばmasterへのマージ後にCIパスしたらbintrayにdeployする みたいな処理を扱いやすいのがポイント．

box: wercker/android
build:
  steps:
    - script:
        name: show base information
        code: |
          gradle -v
          echo $ANDROID_HOME
          echo $ANDROID_BUILD_TOOLS
          echo $ANDROID_UPDATE_FILTER
    - android-sdk-update:
        filter: platform-tools,extra-android-m2repository,extra-android-support
    - setup-android-emulator:
        target: android-22
    - script:
        name: run gradle connectedAndroidTest
        code: |
          gradle --full-stacktrace -q --project-cache-dir=$WERCKER_CACHE_DIR connectedAndroidTest
  after-steps:
    - script:
        name: inspect build result
        code: |
          pwd
          ls -la ./app/build/outputs/
          cp -r ./app/build/outputs/* ${WERCKER_REPORT_ARTIFACTS_DIR}

References

• Testing Support Library | Android Developers
• 2015年7月時点でのJUnit4やEspressoを使ったAndroidアプリのテストについて - Qiita
• Androidのビルドとテストをwerckerで自動化する - Qiita
• Unable to run tests with Android and 1.3 · Issue #18 · crittercism/dexmaker

Libraries

• Robolectric
• hamcrest
• AssertJ
• AssertJ Android
• Mockito
• PowerMock