exclude group: ‘javax.inject’してinjection系のjava.lang.NoClassDefFoundErrorを回避する

espressoを導入するためにcom.android.support.test.espresso:espresso-core、com.android.support.test:testing-support-libをインストールします。 そうすると、テスト実施時に というようなエラーを確認できることがあります。 このエラーはDaggerやRoboGuiceを導入していると確認されました。これは、espressoのjavax.injectが競合しているから発生している模様です。なので、以下のようにexclude groupで指定してあげると、回避できます。 ここらへんのpom.xmlなんか眺めていると、確かにjavax.injectが依存関係で確認できますね。 なるほど。 関連 stackoverflow★More

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

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

Pactのサンプルを動かしてみた

Constomr-Driven Contract PatternのPactのexampleを実施して動きを観察してみました。 GitHub: https://github.com/realestate-com-au/pact 対象 zoo-app zoo-app配下で、以下のコマンドを入力します。 MockServerがService Providerの役割を担います。 Service Customerである ZooApp::AnimalServiceClient がテスト対象です。 ここのテストでは、CustomerがProviderに対して成立させたい機能のリクエストを送り、それに対してProviderが成功/失敗の応答を行うという振る舞いにたいしてexpectで結果を検証します。 Contractフェイズにおける、Customer => Providerへ使いたいサービスの契約を実施しようとするときのもののようです。 animal-service animal-service配下で以下のコマンドを入力します。 Service Providerに対するテストなので、ProviderにConsumerに対するテストデータを保存しておき、Providerに対するリクエストに対して正しく応答ができるか、をテストしています。 そのため、想定したHTTPリクエストが正しく行われているか、が主なテストの合否判定になりますね。 締め Customer-Driven Contracts Pattern自体、サービス間の関係性を確認するためのパターンです。そこに限ってテストを実施するのであれば関係性を確認するときのやりとりをテストすることに限定されそう。 Consumer-Driven Contractsを採用するのであれば、この関係性が破綻しないように正しくすることは必須要素なので、これのようなシンプルさがあったほうが良さそう。 なるほど。 以下のpactoも、振る舞いとしては同じことを確認しようとしてそうです。テストダブルとか、そこらへんの機能は必要性が増えたら見てみようと思います。 https://github.com/thoughtworks/pacto http://thoughtworks.github.io/pacto/patterns/cdc/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

KarmaのMicroserviceへの取り組みを読んでみた

KarmaのMicroserviceへの取り組みを読んでみた。 検索する限りでは、以下URLの企業のよう。 https://yourkarma.com/ Microserviceにおける、個々のサービスがコミュニケーションする方法として以下の2通りを用いているそうな。 Communicate each other with HTTP requests Communicate each other with a message queue この中で、HTTPリクエストベースで、あるサービスから別のサービスへメッセージを投げる形をはじめはとっていたけれど、これはサービスが増加してきたらより複雑になってくるからmessage queueを使うようになってきたとか。 実現のため、Amazon SNSをイベントを配信するために使い、Amazon SQSをそれらイベントを蓄積するためにつかったそうな。プロセスが成功したらjobがQueueから取り出され、進行し、削除される。もしプロセスが失敗すれば、そのプロセスはqueueに戻ってくる。 新しいマイクロサービスが追加されたら、そのサービスはメッセージのタイプを受け取るか、何のメッセージを配信するかという設定ファイルを読み込む。Fareと呼ばれる内省ツールを使っている。 The Biggest Challenge is Testing とあるように、系として如何にテストするか、が大きな挑戦だと言っていたところが面白かった。 この記事のコメントのところに、Pactの話も出ていて、Consumer-Driven Contracts Design Patternはサービスごとの依存性を緩和する手段としてベストプラクティスになりつつあるのかなという感じを受けました。More

Consumer-Driven Contracts Design Patternを読み漁ってみた

Microserviceのテストの話を調べていると、以下のような記事を見つけました。 Simplifying Micro-Service testing with Pacts このPactoと呼ばれるツールがConsumer Driven Contractsと呼ばれるデザインパターンを使っていると書いていたので、同デザインパターンを少し調べてみました。 関連: MartinFowler氏のブログ記事 Pactoに関するGitHub デザインパターンとしての説明 http://www.servicedesignpatterns.com/WebServiceEvolution/ConsumerDrivenContracts http://java.dzone.com/articles/application-pattern-consumer アプリの実装寄りの話はこの記事が参考になりそう 消費者主導契約を使ったサービス指向開発 元記事 Consumer-Driven Contracts Design Patternをざっくりいうと Consumer-Driven Contract patternは、Consumerが取得可能な必要なサービスをProviderと共有(規約)し、Customerごとに特定のサービスのみをProviderから利用可能にするパターンです。 特定のCustomerが使う機能をProviderから取得することで、Customerは限定された範囲の機能を利用します。CustomrはProviderにより提供されるであろう機能の取得を試み、契約(Contract)を成立させようとします。このとき、Customerが利用する機能の補助的な説明をProviderに提供することもできます。ここで契約が正常に成立すると、サービス実行時には基本的にCustomerは契約の成立した機能を使ってProviderからサービスを受けます。 Customerが使っている機能はProviderに適宜提供されます。ProviderはすべてのCustomerが利用している機能の規約の集合をもちます。 登場人物 Provider contracts Providorから提供されているサービスに関する規約。XMLなどで記載される。 Consumer contracts Provider Contractのうち、個々のCustomerが必要とする範囲の規約 個々の消費者が必要とするサービスの契約 Consumer-Driven Contracts(消費者主導契約) Service Providerが満たすべき全Consumer Contractsの集合を書いた規約 Summary of Contract Characteristics MarfinFowler氏の記事のなかで、Provider,Consumer,Consumer-Drivenのそれぞれがどのような関係を持つものかをまとめたもの。 Contract Open Complete Number Authority Bounded Provider Closed Complete…More

Broad Stack Testとは

Broad Stack Testに関して、Testing Strategies IN A Microservice Architectureを読んだで言及されていたので少し調べてみました。 Martin Fowler氏がこの記事にて言及しているテストタイプです。同記事では、end-to-end testや、full-stack testに似ていると書いています。 Broad Stack Testは、SelneiumやSahiのようなツールを使い、UI越しに実施されるテストだそうです。テストピラミッドにおいてもUIテストに区分されると書かれていたので、Microservicesにおいて末端のユーザが使うUI越しの操作をテストする、というテストタイプのようです。 なるほど。More

Testing Strategies in a Microservice Architectureを読んだ

2014年11月18日に公開された、Testing Strategies in a Microservice Architectureを読んでみました。Microservicesに対するテスト戦略に関する大まかな方針を書いています。想像した通りだったのですが、理解しやすく、例も記載しているので取り組む人はいったん読んでおいたほうが良さそうです。 http://martinfowler.com/articles/microservice-testing/ 目次 Some Definitions What is a microservice ? Anatomy: a loook inside a microservice Architecture: choreographing service then the Testing Strategies… Unit: mockist vs classic Integration: datastores and eternal services Component: in or our of process ? Contract: ensureing consistency across boundaries End-to-end: tips and tricks the some…More