モバイルアプリの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
Tag Archives: automation
espressoをたしなんでみた
前年末頃、espressoも2.0になり、JUnit4も使えるようになったAndroidのテスト環境。 既存コードの対応を考えるとJUnit4対応も考えないといけないですが、それに見合うだけのメリットが出てきた気がします。 espresso 2.0 release note サンプルプロジェクトはこちらにありました。 私はiOSと合わせてAndroidに関してもAppiumを選定していたのですが、espresso2.0の登場により、役割とテストレベルに応じてViewを含んだテストを行うときに程よい区分ができそうです。結構、良い補完関係を持つツールだなと感じています。 Appiumの特徴は、リリースapkを直接テストできることだと思います。つまり、一般ユーザがそのまま使う操作に近いUI操作を模倣することができます。そのため、様々なテストレベルにおけるテストを実施したのち、E2Eレベルでの、システム全体としてのテストを実施することができます。 espressoの特徴は、やはりViewを構築しながらも実行の速さを出せるところだと思います。そのため、mock serverなどを用意して、短い時間にUIのレイアウト確認を実施することができます。Hermetic testとしてのテスト環境により適しているかもしれませんね。また、JUnitで記述するので、CIに程よく組み込めそうです。 いずれもテスト環境の構築で変化する要素は多分にありますが、Viewの確認を行うにしても、それぞれが得意とする分野は異なるので、テスト戦略や計画、設計に応じた使い分けができれば良いと思います。この箇所は、テストのしやすさがiOSと異なりますね。 espressoを少し espressoのサンプルです。先ほどのGitHub上のサンプルコードより引用しています。 R.id.operation_mul_btnと、要素の指定はidの直接指定をこなうことで要素の特定をしているようです。API18以上だとresoirce_idの直接指定ができるようになったものと同様な感じで要素は指定するようです。 espressoのCheatSheetに以下の画像がありました。 これを見ても、espressoは画面単位で、期待した描画ができているか、というところに焦点を当ててテストを書くことが適していそうです。 想定したユーザシナリオを実施できるかは、Appiumが良さそう。More
Appium 1.3.5 beta released!!
Appiumの1.3.5がリリースされていた。 1.3.4では、環境によってはadbコマンドかinstrumentsへのコマンドが正しく動作しないことがあったのでmasterブランチを追ってましたが、これでnpmの世界で過ごせる! 比較的大きなものとしては、iOS8.2の対応とかでしょうか。とはいえ、対応バージョンの追加などの比較的細かな所になりますが。 あと、Androidに関してはUiAutomatorあたりでworkaroundが入っていたりとするので、AndroidでUiAutomor使っている人には良いのでは。 何も問題なければ、多分1.3.5はこのままリリースされるはず。 https://discuss.appium.io/t/appium-1-3-5-beta-released/2511 iOSアプリで要素を取得するとき、Appium.app経由だと取得できる要素が、コマンドラインから起動したAppiumサーバ経由だと取得できないものに出くわしたのですよね。 ??と思って、コマンドラインのAppiumサーバ経由で起動したあと、inspector経由でアクセスすると、確かに見えない。 これは何だ。。。と疑問に思って調査しようとおもってはいるのですが、致命的というわけではないのでんーという感じでうやむやに。 そろそろ、コード書いて、コードを読む量を増やしたい機運。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 1.3.3 released !!
Appium 1.3.3 がリリースされましたね。安定性も上がってきた模様。 1.3.3といいつつも、中身は1.3.2で計画していたものです。 詳細は以下をご覧いただければ良さそう。 https://discuss.appium.io/t/appium-1-3-3-released/1452 中でも、 add a sendKeyStrategy capability to allow testers to enable less reliable, but faster sendKey method が追加されたのは助かりますね。 一時期、sendKeyStrategyが1.3.1のものに変更されたのですが、そこがcapabilityで選ぶことが可能になったものです。 私が使っているテストスクリプト自体のiOS8やiPhone6/6+への対応も安定段階に入り、また継続して使えそう。Androidにも同様に本格的に取り組んでいきたい。 iOSでは、Xcode8.2の足音も聞こえ始め、シミュレータの安定性なんかが気になりますね。More
The Google Test Automation Conference (GTAC)を聞いてみて(on YouTube)
テスト界隈ならご存知の方も多いと思いますが、2014年10月19日に、以下のようにGoogleが主催するテスト自動化カンファレンスがありました。 The Google Test Automation Conference (GTAC) 同カンファレンスの付随情報 YouTube: 1日目, 2日目 Testdroiによるレポート: 1日目, 2日目 sleeping cat syndromeさんによる同レポートの訳GTAC2014まとめ抄訳 GTAC自体の訳に関しては先のレポートやその訳にお任せしようと思います。以下はかいつまんんで。More
Appium1.3.1released!
Appium 1.3.1 が瞬く間にリリースされていましたね。 https://github.com/appium/appium/releases/tag/v1.3.1 今回retryが入れられたfull-resetの問題ですが、full-reset付きでappiumを起動すると以下が実行されるタイミングで、うまくeraceできないというもの。 コマンドラインから一度シミュレータの設定を削除してあげると、次回以降は問題なくコマンドが成功するのですよね。Retry処理を入れたらしいのですが、成功せず。 どこか、権限的なものが関係しているのかな… 私の環境でも1度再現して、コマンドラインから一度削除すると以降はcapabilityを変更してもうまく動作しているので、少しわからない。More
Cloud Test Platforms
SauceLabsなんかを操作していたのですが、類似サービスを少し頭に入れておこうと思いまして、ざっとまとめ。 Testdroid Appiumを使ってテストできるようになったらしい。 サンプル: http://testdroid.com/testdroid/8271/how-to-get-started-with-appium-sample-included#more-8271 AppThwack AppThwackはMonkeyTalkなんかが使える。 Appurify Googleが買収した類似のテストサービス。 国内だと、こういうのはシロッコや AppKitBox に似たやつでしょうか。 今の私の環境では、テスト自動化を目指す場合、API提供だったりが大事なのですがそこらへんを考えると海外のサービスのほうが少し相性が良い。。。More
Appium1.2.3 released
Appium 1.2.3がリリースされましたね。 ios8ブランチでは、1.3-beta1としていくつか不具合はあるもiOS8対応も進んでいるのでもう少しかも。 とはいえ、iOS8 simulatorやinstruments関連でも不具合があるようなので、Apple側対応が必要な箇所もある程度ある模様。 Appium 1.2.3は、1.2.2において1.2.1からいくつかあったエンバグがなおっている模様。 例えば、iOSだとfindElementsのクラッシュやuiautomation predicate searchの修正、AndroidのsetText箇所など。 iOSのscroll操作もなおった模様? 私はscroll操作は使わないようにテストシナリオを修正したので、影響なかったのですが、影響ある人はありそう。More
Appium1.2.1 released !!
Appium1.2.1がリリースされましたね。 https://github.com/appium/appium 既に、結構お世話になっているのですがAndroidに関してはiOSにくらべて不安定だったり、やりたいことを実現できていないことが多いのですが、今回の更新で少し良い意味で気になった箇所をピックアップしてみます。 いくつか小さな不具合修正や、使いやすさ向上は置いておいて。 iOS fix bug with parsing of binary vs XML plists retry getting screenshot if it fails fix error in getting localized strings XMLの修正や、screenshotのretry処理は嬉しい。特に、screentshotはリトライなくてここで失敗するシナリオもあったし。 あとは、Safariで操作するときの振る舞いが安定してきたみたい?いろいろ改善が見られる。 Android fix handling of IME activation support API level 10 style focused activity strings update api level dependency for the project to 19 fix bug with xpath…More