AndroidのアニメーションをOFFにしてFlakyなテストを減らしたい

モバイルアプリのViewに対する自動テストを行おうとした場合、画面遷移時なんかのアニメーションがFlakyなテストにつながることが多々あります。たとえば、Appiumやespressoなどを使って複数のViewを跨いだりする時なんかはよくある話です。 Androidに関しては、開発者オプションの設定により、以下アニメーションをOFFにすることが可能です。 ウィンドウスケール トランジションアニメーション Animator再生時間スケール この設定をOFFにすることで、アニメーションをOFFにした上でViewに対するテストを実施できるようになるので、より安定したViewに対するテストを実施することができます。ただし、この設定をOFFにするとアニメーションが無視されるようになるので、テストレベルとその時々にどんな不具合を検出したいかというテスト設計に沿って、アニメーションを無視する/しないを決めるとよいでしょう。 個人的な感覚では、Androidにおいてはespressoによるテスト実施時はアニメーションをOFFにしてViewの確認、Appium使うときはアニメーションも考慮して確認が良いかなと思っています。これにより、UnitTestingから徐々に確認する領域を増やしていき、テスト自動化のビラミッドのような形に、自動テストの厚みを調整できそうな気がします。 実施方法 以下コード例に沿って、テストユーティリティを実装しておきます。 Android端末におけるAnimationをOFFにするコード例 DisablingAnimations AndroidManifest.xmlに SET_ANIMATION_SCALE を指定する必要があるのですが、Gradle 2.1からは特定のビルドだけ、特定のマニフェストを追加することができる模様。 そのため、たとえば、 ./gradlew coonectedAndroidTest のときのみSET_ANIMATION_SCALEを増やしたい場合、以下のような感じでAndridManifest.xmlを作れば良いみたいです。 src/androidTest/AndroidManifest.xml ここまでの対応をしたのち、テストスクリプトのsetUpにでもアニメーションをOFFにする変更を書き込み、espressoを実施してみます。問題なく動く!!!と思っていたのですが、以下のようなエラーが… Cannot disable animations due to lack of permission. SET_ANIMATION_SCALEを眺めてみると、以下のようにどうやら3rd party製アプリには許可していない模様。 いろいろ調べましたが、これのWorkaroundは以下のようです。 AndroidManifest.xml にSET_ANIMATION_SCALEを許可しているアプリに対して以下adb shellコマンドを実施する 標準出力に特に何も出力されなければ、成功です。システムのアプリケーション情報に、アニメーションの権限が追加されていることを確認することができます。以降、DisablingAnimationsのユーティリティによりアニメーションをOFFにするということが正常に受け付けられるようになります。 ちなみに Appiumにも、1.4になりますが以下のように計画があるようです。 Appium should disable Android’s system animations to reduce flakiness Appiumでは、ツールの作り上、espressoよりも実現しやすそうとも思うのですが時期があえばなんらかのコミットもしたいかな。adb shellのやり方に関しても同じところを参照しているようなので、実装方針も思っているのと同じ方針な気がする。 締め アニメーションのOFFはViewに対するテストでFlakyなものを減らすという意味でも何気に必要だったりします。ただ、adbコマンドを毎回使ったりすることが面倒なので、一番楽なのはアニメーションをOFFにしたテスト用端末でテストを実施することだったり… 雑談ですが、最近、TestFlightから別サービスに移ろうとする流れがありますね。Appleが旧TestFlightをやめると言ったので。 TestFairyとかとか、代替サービスとして探している人も多いですが、そこらへんでテストサービス それらを見てて感じるのですが、落ちバグ発生時、そのクラッシュログを動画付きで取得して、その再現まで自動的に実施できる環境の構築なんかしてみたいですね。技術的な関心なだけですが。ただ、不具合レポートからUI含めた再現をどうやるかなーと思った時、無理そうと思ってしまう。もしかしたらUnit testレベルなら再現できるかもしれないですが、それがユーザ操作として正しく発生しうるクラッシュを防ぐことにつながるか、と考えるとそうとも言えないことを多々経験したので、やって価値あるかなーと考えてしまう。難しいですね。More

DockerでAndroidビルド・Roboletricとも戯れる

Dockerと、Androidのunit test frameworkであるRoboletricと戯れてみました。共に今更感ありますが、ご愛嬌で… Dockerfile 今回作成したDockerfilrと、imageは以下です。 GitHub: https://github.com/KazuCocoa/docker-appium Docker: https://registry.hub.docker.com/u/kazucocoa/docker_android_testpack/ Docker Hubにあげているので、以降は以下コマンドだけでbuildする必要はありません。(いつ消すかわかりませんが…) boot2dockerをMac OS Xにインストールして、環境を構築しました。Dockerfileに、GooglePlayServiceやら含めたAndroidアプリのビルドに必要になりそうなライブラリすべて入れてみました。 Dockerfile書いているとふと思うのですが、Circle CI、完全にymlがDockerfileですね。Travisにくらべても、まんまDockerだと感じました。ちょっと面白かった。 Androidのビルド環境をDockerで作ってどだったか 開発環境としては強いメリットはなさそう。 確かに、環境構築が楽でDockerfileを配布すればOKという開発環境に持っていけそうです。が、多くのAndroidアプリ開発はEclipseやAndroid StudioなどのIDEを使います。そうなると、Mac OS X やLinux、Windowsをそのまま使ったほうが楽そう。 一方、CIとしてDockerを使うとういうのはビルド環境の管理という観点では有用そうでした。ビルド完了後、必要な成果物をマウント先に保存したり、Deploygateなどに上げるとそれで終わり。TEみたいですね。 実機を接続してテスト速度を上げるときは、adbコマンドのtcp接続すればよさそう。(有線より不安定な可能性ありますが) Roboletric使ってみて Roboletric、以下の通りサンプルコードが用意されているようですね。なので、さっとサンプルコードで手を動かしてみました。 https://github.com/robolectric/robolectric-samples このサンプルで使われているRobolectric3.0-SNAPSHOTはまだ正常に動作しない模様。(2015/01/14現在)。Roboletric 2.4とAPI 19向けにアノテーションを加えたコピーを作成して実施してみました。 https://github.com/KazuCocoa/sampleRoboletricTests 正常にテストを実施しても、API 21でテストが失敗しますがRoboletricのAPI 21対応が3.0なので、一旦は気にしないことに。 締め Roboletric + GradleでTDD for Androidを実施しようというライブラリもありました。こちらも少し手をつけてみようと思います。 https://github.com/robolectric/deckard-gradleMore

Appium x Androidの要素指定の手段にtext要素による指定を追加した

Appiumを使ってiOS/Androidの要素を取得する方法の数々に以下のAndroidによる要素の取得方法を追加しました。 Androidでは、Android SDKに同封される uiautomatorviewer コマンドで要素を表示確認します。そのツールで text 要素に表示される文言からその要素を特定する場合、上記のようにXPathの記述で要素を特定することが可能です。 利点 contentDescription指定が不要 表示されている文言ベースで要素を指定可能 比較的手軽 欠点 TextViewやButtonなど、表示される要素が異なると使い分けを行う必要がある 共通でresorceIDやcontentDescriptionで指定可能であれば、そのような使い分けはしなくてもよくなる テキストが表示されない要素を特定することは不可能 UIの表示文言にテストの安定性が左右される システムの言語設定に依存したり… ここまで揃えば、iOS/Android共に多くのシナリオを比較的容易に自然言語でシナリオ自動化できそう。More

モバイルアプリのCIサービスが増えてたのでいくつか使ってみた

iOS/AndroidのCIサービスがまた増えてきたようなので、少し触れてみました。安定性はやはり以前からあるものが良さそうですが、今年は選択肢の多様化と価格競争も進みそうですね。あとは対Enterprise向けサービスも今はTravisだけですが他の選択肢も出てきそう。 今まで触れたことのあるCI環境 Travis CI, Travis CI Enterprise Wercker CloudBees Hosted CI 新たに触ってみたもの GreenhouseCI Ship.io Circle CI 試したことは、適当なサンプルプロジェクトを、GitHubのPushなどを契機にビルドするということです。それぞれのサービスの制限(ディクス容量や、時間制限など)までは確認していません。 GreenhouseCI ビルド対象はRepository URLの直接指定で行います。Publicなものであればそのままビルドすれば良いのですが、username & passでのログインやSSHの利用が提供されているので、private repositoryも対象にすることができます。 ビルド設定すると、Cloneしてきて、Android/iOSを識別、いったんビルドを試します。その後、スキャンしたビルドオプションをプルダウン形式で選ぶことができるので、そこで次回以降実施するものを選ぶことができます。 GitHubのWebhookに所定のURLを設定したら、GitHubへのイベントをきっかけにCIを回すことができるところまでサポートされている模様。 Ship.io GitHubに接続し、リポジトリを指定してビルドを開始します。こちらはまだBeta版らしく、動作が重たいです。 重たかったので、ちゃんと試せていないです… Circle CI Android、iOS共にビルドできそうだったけれど、iOSをビルドしようとすると以下のような文言が表示されました。まだBetaなので、気長に待つことが必要そう。 Warning: Sorry! Your build didn’t run because we are still adding capacity to the iOS beta and haven’t enabled your organization yet. We know…More

GoogleAPIを利用可能なインテルのx86による高速化対応可能なAndroidエミュレータシステムイメージの作成

Androidエミュレータを使って自動テストをまわそうと思っても、エミュレータの起動速度が通常は遅いですよね・・・ その高速化方法として、インテルのx86向け高速化オプションを現在のAVDでは選択可能です。 しかし、GoogleAPIを利用可能な版は提供されていない・・・ ということで、今回は実際に行ったGoogleAPIを利用可能にしたインテルx86高速化対応版システムイメージの作り方をメモがてら。 参考1: http://t-tech.hatenablog.com/entry/2012/07/27/151705 参考2: http://isisredirect.blogspot.jp/2013/04/test-titanium-android-app-on-emulator.htmlMore