既にRubyだとやってる人がいて便利そうだったので、Groovy(Java)でも書いてみた。
個人的に最低限、知っておいた方が良いと思うこと
以下の資料に詳しく書いてあります。
Android UIテストフレームワークのひとつEspressoは今年の1月からずーっとコミットがなさそうで、これはもうお亡くなりになったのか。。。と思っていたら突如2.0が発表されました。
ということで早速試してみたのでメモ。 (細かい所までは見れてないです)
上記に記載したようにGoogleが2013年に発表したUIテストフレームワークのひとつです。
AndroidのUIテストフレームワークはrobotiumやuiautomatorなんかがありますね。 calabash-androidというのもあります。
その中でEspressoの特徴ですが、とにかく実行速度がめちゃめちゃ早いことだと思います。
robotiumとの実行速度比較は以下のスライドで見れます。
作成するアプリの画面が少なければ問題ないかもしれませんが、そうでない場合に相当数のUIテストが必要で、そのUIテストに何時間も掛かるようでは継続的インテグレーションへの導入も難しいと思います。そういった意味でEspressoはとても魅力的なテストフレームワークの一つではないかと思います。
詳細はリリースノートを見ていただくとして以下が気になった変更点です。
最初に書いたようにEspressoはGoogle製のフレームワークにも関わらず、今年に入って更新がほぼなくオワコン感があったのですが、今回の2.0はAndroid Support Repositoryの一つとなり、ドキュメントがAndroidDevelopersサイトへ移行予定とのことなのでAndoridとして推奨のUIテストフレームワークの一つに昇格したのではないかと思います。
Espresso1から2への移行を行ってみます。手順はこちらに記載があります。
最初から2を試したい人は以下に既にGoogleがサンプルプロジェクトを用意してるのでこちらを利用するのが手っ取り早いと思います。（ただし、AndoridSupportRepository最新版のダウンロードは必要)
Android-Testing Github Samples
最終的に変更したものはGithubに配置しています。(robolectric/deckard-gradleを利用して変更しました)
なお、こちらにあるように実機かEmulatorで開発者メニューの一部は変更済みの想定です。
Espresssoに関連するjarファイルはAndroidSupportRepositoryから取得できるようになったので、lib配下のものは参照せず、パッケージ名を明記する方法にbuild.gradleを変更します。
- androidTestCompile files('lib/espresso-1.1.jar', 'lib/testrunner-1.1.jar', 'lib/testrunner-runtime-1.1.jar')
+ androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'
+ androidTestCompile 'com.android.support.test:testing-support-lib:0.1'
lib配下のjarファイルが不要になるので削除します。
$rm lib/espresso-1.1.jar $rm lib/testrunner-1.1.jar
Espressoテストコードのパッケージ名をcom.google.android.apps.common.testing.ui.espressoからandroid.support.test.espressoに変更します。
-import static com.google.android.apps.common.testing.ui.espresso.Espresso.onView; +import static android.support.test.espresso.Espresso.onView;
上記のように関連箇所を置換します。
AndroidSDKManagerを開いてExtra配下のAndroid Support Repositoryを最新版(rev11以上)をダウンロードします。
ダウンロードが成功すれば$ANDROID_HOME/extras/andorid/m2repository/com/andorid/support/test配下にespressoとtesting-support-libフォルダが存在が確認できます。testing-support-lib配下のpomを見るとjunit4.10に依存している記述があり、このファイルからもJUnit4対応が確認できます。
テストランナーがGoogleInstrumentationTestRunneからAndroidJUnitRunnerになったのでbuild.graleを変更します。
- testInstrumentationRunner "com.google.android.apps.common.testing.testrunner.GoogleInstrumentationTestRunner" + testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
エミュレーターや実機を繋いて以下を実行します。
$./gradlew clean connectedAndroidTest
成功していればBUILD SUCCESSFULと表示されると思います。
最終的なbuild.gradleは以下のようになりました。
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0-rc4'
}
}
allprojects {
repositories {
mavenCentral()
}
}
apply plugin: 'com.android.application'
android {
packagingOptions {
exclude 'LICENSE.txt'
exclude 'META-INF/LICENSE'
exclude 'META-INF/LICENSE.txt'
exclude 'META-INF/NOTICE'
}
compileSdkVersion 19
buildToolsVersion "19.1.0"
defaultConfig {
minSdkVersion 18
targetSdkVersion 18
versionCode 2
versionName "1.0.0-SNAPSHOT"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
sourceSets {
androidTest {
setRoot('src/test')
}
}
}
dependencies {
repositories {
mavenCentral()
}
compile 'com.android.support:support-annotations:20.0.0'
// Espresso
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.0'
androidTestCompile 'com.android.support.test:testing-support-lib:0.1'
}
せっかくなのでテストコードをJUnit4で書いてみることにしました。 ドキュメントは以下を参照。
User guide for AndroidJUnitRunner
なお、ドキュメントにも書いてあるようにJUnit3でも動くので特に昔のコードを変更する必要はなさそうです。 対応する場合には以下が必要です。
import org.junit.Before; import org.junit.After; import org.junit.Test; import org.junit.runner.RunWith; import android.support.test.runner.AndroidJUnit4; import android.support.test.InstrumentationRegistry;
@RunWith(AndroidJUnit4.class)
@LargeTest
public class DeckardEspressoTest extends ActivityInstrumentationTestCase2<DeckardActivity> {
@Before
public void setUp() throws Exception {
・・・
}
@Test
public void testHoge() {
・・・
}
@After
public void tearDown() {
・・・
}
ActivityInstrumentationTestCase2を利用する場合、@Before内で手動で以下を実行する必要があるようです。
injectInstrumentation(InstrumentationRegistry.getInstrumentation());
これを実行しないとgetActivityメソッドでnullが返却されてテスト結果がエラーとなってしまいました。
エミュレーターや実機を繋いて以下を実行します。
$./gradlew clean connectedAndroidTest
Espressoのリリースノートに
What about WebView support? While testing internally, we discovered some issues, which required major changes. We are putting the finishing touches on a new and improved API - it is coming shortly and it promises to be awesome.
とあるのでそのうちWebViewサポートがくるかもしれません。
また、Espressoではできないと思いますが、AndoridStudio1.1devでMockableJarタスクが追加されてているのでAndoridの単体テストは実機やエミュレーターががなくても実行できるようになりそうです。
With Espresso 2, JUnit 4, mockable android.jar, and first-party unit test support coming in Gradle & AS, things are looking up for testing!
— Jake Wharton (@JakeWharton) December 20, 2014.@crazybob's mockable android.jar lives on as the first-party unit test offering coming in 1.1.
https://t.co/AKe7OVhbT1
— Jake Wharton (@JakeWharton) December 20, 2014android / platform/tools/base / e8f845b47459973838c99656ae98563b268f21ff^! / .
やってることとしてはASMを使ってandroid.jarのStubExceptionが発生させないように置き換えて各メソッドはデフォルト値を返すようにするようです。（挙動を変える場合にはmockitoを使うっぽい)
GradleでNDKサポートも行っているようですが、基本的にAndroid.mkは既存のものは使わず、自動生成するようになったようです。
シンプルな構成ならば指定された場所にファイルを移動したりすれば良いのですが、現在自分が担当しているプロジェクトはAndorid.mkがとても複雑化しており、既存のAndorid.mkを利用したまま、Gradleによってビルドする方法を試してみたのでそのメモを書きます。
検証ではNDKに最初から入っているサンプルプログラム(hello-jni)を利用します。
toshihirock/AndroidNdkGradleSample
まずはいつも通りantでビルドしてみます。(ここは別に実施しなくても良いですが一応ビルドできることの確認)
$cd ${NDK_HOME}/samples/hello-jni
# targetIDを確認してから、antのビルドで必要なbuild.xmlを生成
$android list target |less
$android update -p . -t 1
# ndk-buildする
$ndk-build
# antでビルド
$ant debug
# アプリをインストール
$adb install bin/HelloJni-debug.apk
手っ取り早くGradleでビルドするようにbuild.gradleを作りたいのでEclipse with ADTを使います。
作成後、build.gradleの以下の２箇所を変更します。
# andorid-gradle pluginを最新化 - classpath 'com.android.tools.build:gradle:0.12.+' + classpath 'com.android.tools.build:gradle:1.0.0-rc4' # plugin正式名称が変わったので対応 - apply plugin: 'android' + apply plugin: 'com.android.application'
デフォルトのgradlewのバージョンが1.12となっているので新しくします。現在の1.0.0-rc4ではgradle2.2.1が必要なので変更します。
$vi gradle/wrapper/gradle-wrapper.properties - distributionUrl=http\://services.gradle.org/distributions/gradle-1.12-all.zip + distributionUrl=http\://services.gradle.org/distributions/gradle-2.2.1-all.zip
とりあえず動くかタスクを見つつ確認。
$./gradlew tasks
ネイティブコードのビルドはCLIからndk-buildを実行します。
$ndk-build
上記状態でlibs/armeobiなどの配下に.soファイルが出来ていることが確認できます。
一度この状態でgradleだけでビルドしてみます。
$./gradlew assembleDebug
ビルドが終わってapkができます。パスはbuild/outputs/apk/hello-jni-debug.apkとなっております。
ただし、これにはNDKでビルドを行なった場合に必要な.soファイルが含まれていません。(unzip hello-jni-debug.apkで中身が確認できます。)起動しようとしても.soファイルがないのでエラーが発生し、起動できません。
上記で.soファイルがapkのパッケージングの際にされないのはAndroidGradleプラグインで想定されている箇所に.soファイルが存在しないためです。なお、想定されているパスはsrc/main/jniLibsとなります。
build.gradleを見ると分かるのですが、実はそもそもjavaファイルなどの場所もAndroidGradleプラグインで想定されているものとは違うため、明示的にbuild.gradleに記載されている事がわかります。
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
}
AndoridStuidoへの移行を契機にAndoridGradleプラグイン(mavenのプロジェクト)の想定するパスに変えた方が良いと思いますが、とりあえずは既存の状態で対応させていく方法をとります。
.soファイルの存在する場所をbuild.gradleに伝えるためにjniLibsプロパティを追加します。
main {
manifest.srcFile 'AndroidManifest.xml'
java.srcDirs = ['src']
resources.srcDirs = ['src']
aidl.srcDirs = ['src']
renderscript.srcDirs = ['src']
res.srcDirs = ['res']
assets.srcDirs = ['assets']
jniLibs.srcDirs = ['libs']
}
これで準備ができました。 既に.soファイルは出来ているのでgradleを使って再度ビルドします。
$./gradlew assembleDebug
同じようにapkをunzipすると今度はlibフォルダもパッケージングされていることが確認できます。 当然、アプリとしても動作が可能です。
ndk-buildもgradleで実行したいのでタスクを追加します。
冒頭でも書いているようにAndoridGradleプラグインでもNDKのビルドをしようとするのですが、今回は必要ないのでjniプロパティに何も設定しないようにしておきます。(本構成の場合、規定されたパスにネイティブコードはないのでどうせビルドされないですが。。)
sourceSets {
main {
・・・
jni.srcDirs = []
}
また、ndk-buildコマンドを実行するための追加のタスク及びcleanタスクやJavaCompileのタスク実行時にndk-buildが実行されるようにします。
// ndk
ext {
ndkHome = '/Users/toshihirock/android-ndk-r10d/'
}
tasks.withType(JavaCompile) {
compileTask -> compileTask.dependsOn ndkBuild
}
clean.dependsOn 'ndkClean'
task ndkBuild(type: Exec) {
println "exec ndk-build"
commandLine "${ndkHome}ndk-build"
}
task ndkClean(type: Exec) {
println "exec ndk-build clean"
commandLine "${ndkHome}ndk-build", 'clean'
}
自分の環境で試す場合にはndkHomeプロパティを変更するなり、build.propertiesに記載したり、環境変数から取得するなりしてください。
cleanタスクとassembleDebugタスクを実行すると一緒にndk-build cleanとndk-buildも実行されます。
$./gradlew clean assembleDebug
GradleでJenkinsのコミットメッセージを取りたかった(deploygateのメッセージにJenkinsのコミットメッセージとビルド番号を入れたかった)のでGradleスクリプトを作ったのでメモ。
Gitsにも置きました。
// something
// jenkins
import groovy.json.*
ext {
jenkinsUrl = 'http://localhost:8080'
buildNumber = System.getenv("BUILD_NUMBER");
jobName = System.getenv("JOB_NAME");
println "build number is ${buildNumber}"
println "jobName is ${jobName}"
}
def getJson(url) {
println "start getJson $url"
def response = new URL(url).text
return new JsonSlurper().parseText(response)
}
def getJenkinsMessage(message) {
def url = "${jenkinsUrl}/job/${jobName}/${buildNumber}/api/json"
def items = getJson(url)['changeSet']['items']
items.eachWithIndex() { obj, i ->
message += obj['msg'] + ' '
}
return message
}
task jenkins << {
String message = "B${buildNumber} "
println getJenkinsMessage(message)
}
【初心者でも】やろうぜGroovy!〜ファイル読み書きしたり、Web APIたたいたり、レスポンスの中身確認したり〜編【今すぐ使える】