Android Testing Support Library（ATSL）バージョン 1.0 がリリースされました。 　
　
ATSL バージョン 1.0 は既存のテスト API のメジャー アップデートで、たくさんの新機能、パフォーマンスの改善、安定化、バグ修正が含まれています。サポート終了となった Android プラットフォームのテスト API と同等の機能もすべて提供されています。今回のリリースには、マルチプロセス Espresso のネイティブ サポートや、Android Test Orchestrator など、Google I/O 2017 のセッションでお話しした多くの機能も追加されています。 　
　
うれしいことに、ATSL はバージョン 1.0 より、Google の Maven レポジトリで公開されるようになりますので、皆さんのビルドで簡単に使っていただけるようになります。このレポジトリの詳しい利用方法については、Google Maven レポジトリ利用ガイドをご覧ください。なお、今後はプラットフォームのアップデートにテスト用インフラストラクチャのアップデートは含まれなくなりますので、ご注意ください。まだテストを ATSL にアップグレードしていない方は、ぜひこのタイミングでアップグレードしましょう。 　
　
もう一点、Android のテスト ドキュメントの大規模な改訂についてもお知らせします。古いテスト ドキュメントは、GitHub ウェブサイトから developers.android.com/testing に移行されており、すべてのテスト ドキュメントが 1 か所で参照できるようになりました。そのため、Android でテストを書いたり実行したりする方法を調べやすくなっています。 　
　
それでは皆様お待ちかねの、今回のリリースで提供される新しい API の概要とツールについてご説明します。 　
　

Espresso の改善


Espresso 3.0.0 には、すばらしい新機能が搭載され、全般的なパフォーマンスが改善されています。主な機能として、マルチプロセス Espresso、アイドリング レジストリ、新しいアイドリング リソースなどがあります。これらの新機能についてさらに深く掘り下げてゆきましょう。 　
　
マルチプロセス Espresso 　
　
Android O 以降では、アプリのデフォルト プロセス外の計測テストがプラットフォームでサポートされています（Android O より前は、アプリのデフォルト プロセスでアプリのコンポーネントをテストすることしかできませんでした）。マルチプロセス Espresso は、そのテストを可能にします。これは、Espresso による同期を保証しつつ、プロセス境界をまたいだアプリの UI インタラクションのテストをシームレスに実行できるようにするものです。 　
　
うれしい点は、Espresso がすべての作業を行ってくれることです。設定を一切変更せずに、UI を複数プロセスで操作できます。Espresso テストは、単一プロセスのアプリと同じように記述できます。Espresso が自動的にプロセスの IPC を処理し、プロセス間の同期をとってくれます。 　
　
次の図は、Espresso の複数のインスタンスがお互いに通信する仕組みを示しています。 　

マルチプロセス Espresso の詳細や使用方法を知りたい方は、ドキュメントやマルチプロセスのサンプルをご覧ください。 　
　
アイドリング レジストリ 　
　
アプリの中には、Gradle のビルド フレーバーや Dagger などの依存性注入フレームワークを使ってアイドリング リソースを登録するテストビルド設定を生成しているものもあるでしょう。また、アクティビティを通して単純にアイドリング リソースを公開しているアプリもあるでしょう。こういったアプローチで問題になるのは、開発ワークフローが複雑になり、カプセル化が破られてしまう場合があることです。Espresso の最新リリースでは、アプリのコードからのアイドリング リソースの登録が簡単になっています。これは、新しい IdlingRegistry API を使って実現されています。IdlingRegistry は、Espresso ライブラリ全体を取り込まずに使える軽量レジストリです。そのため、アプリのコードから簡単にリソースの登録を行うことができます。この API をマルチプロセス Espresso と組み合わせると、アプリのコード内の任意のプロセスからアイドリング リソースを登録できます。 　
　
Espresso クラスから登録を行う機能は、サポート対象外となっています。 　
　
アイドリング リソース 　
　
カスタムのアイドリング リソースの記述は時間がかかるものです。そのため、Espresso 3.0.0 には、スレッドの同期を行う際に簡単に利用できるさまざまなアイドリング リソースが搭載されています。新しく追加されたリソースには、IdlingThreadPoolExecutor や IdlingScheduledThreadPoolExecutor などがあります。今後も、さらに追加される予定です。

新しいアイドリング リソースを活用するには、新しく追加された次の依存関係を build.gradle ファイルに追加します。 　
  androidTestCompile "com.android.support.test.espresso.idling:idling-concurrent:3.0.0"

さらに、今回のリリースでは、以前に Espresso の contrib パッケージでサポート対象外となっていた CountingIdlingResource が削除されています。そのため、Espresso のアイドリング リソースに配置されている新しい CountingIdlingResource のパッケージを使ってテストをアップデートする必要があります。詳しい移行方法については、リリースノートをご覧ください。 　
　

ProviderTestRule


ContentProvider オブジェクトをテストする場合は、ProviderTestCase2 の代わりに ProviderTestRule を使うことができます。ProviderTestRule では、現在 AndroidJUnit4 で利用できる他のテストルールと簡単に連携できる方法が提供されています。 　
　
ProviderTestRule には、初期化用 API や、テストの際に ContentProvider に対して実行するコマンドが含まれています。SQLite データベースに基づく ContentProvider を使っている場合は、ProviderTestRule コマンドを使ってデータベース ファイルや初期化コマンドを設定できます。 　
　
詳細については、ProviderTestRule のドキュメントをご覧ください。 　

パーミッション付与ルール


Android M（API レベル 23）では、実行時にアプリがパーミッションをリクエストできるようになっています。ただし、実行時にパーミッションをリクエストするダイアログによって、テストが継続できない状態になり、結果としてテストが失敗する場合があります。GrantPermissionRule を使うと、ダイアログのポップアップを完全にスキップし、ユーザーが実行時にアプリにパーミッションを与えた状態をシミュレートすることができます。 　

Android Test Orchestrator


通常、AndroidJUnitRunner は、同じ計測プロセスのすべてのテストを実行しますが、これによってさまざまな問題が起こることがあります。たとえば、複数のテストがメモリ内で状態を共有している場合、1 つのテストがクラッシュすると、残りのテストスイートが実行できなくなります。 　
　
連続して複数の adb コマンドを発行すれば、別々にテストを行うこともできますが、ホスト側の処理の負荷が増加することになります。新しい Android Test Orchestrator を使うと、次の図のように、端末上でテストを完全に分離することができます。 　

ただし、テストが成功するために状態を共有することが 必要 な場合、Orchestrator を使うとテストが失敗することになります。この動作は、意図的なものです。本投稿の執筆時点で、Android Test Orchestrator はベータ版であり、コマンドラインから利用するものとなっています。近日中には、Firebase Test Lab と Android Studio への統合が行われる予定です。 　
　
詳細については、Android Testing Orchestrator デベロッパー ガイドをご覧ください。 　

AndroidJUnitRunner


AndroidJUnitRunner にも、次のような追加機能が搭載されています。 　
  • JUnitParams が利用可能になりました。
  • Runner の引数を使ってクラスローダとカスタム JUnit テストフィルタの設定を行えるようになりました。

テスト ワークフローの一環として、暫定的に作成、設定したアクティビティのテストを行いたい場合もあるでしょう。そのような場合に、InterceptingActivityFactory を使って MonitoringInstrumentation（さらに、拡張機能として AndroidJUnitRunner）を設定できるようになっています。テストの際には、コンパイル時のインジェクションに依存せずに、テスト固有の設定のアクティビティを作成できます。 　
　
本投稿で紹介した概要は、ATSL に対するもっとも重要な変更点のほんの一部を紹介したものです。知っておくべき変更点は、まだ他にもたくさんあります。詳しいリリース内容については、リリースノートをご覧ください。 　
　
最後になりますが、今回リリースされた機能に貢献してくださったすべてのデベロッパーの皆さん、どうもありがとうございます。また、私たちに協力し、Android Testing Support Library のプレリリース版に貴重なフィードバックをお寄せくださった American Express モバイル エンジニアリング チームの Android テストのエキスパート、Slack、GDE の Chiu-Ki Chan に感謝いたします。 　
　
ATSL チームは、皆さまのテストの成功をお祈りしています。 　
　
　

Reviewed by Yuichi Araki - Developer Relations Team

Android 7.1 Developer Preview 上で Flood-It! アプリのクラッシュを発見する Robo テスト



Posted by Takeshi Hagikura - Developer Relations Team


長らくお待たせしました。iOS 向けの UI 機能テスト フレームワーク、EarlGrey のリリースをついに発表できる時が来ました。YouTube、Google カレンダー、Google フォト、Google 翻訳、Google Play ミュージックなど、Google アプリの多くが、機能テストのニーズに応えて、このフレームワークに対応しました。

EarlGrey で提供している主な機能は次のとおりです。
  • 強力な同期機能: テストでは、UI の操作をする前に、アニメーション、ネットワーク要求などのイベントが終了まで自動的に待機します。その結果、テストの記述が容易になり（スリープや待機状態が発生しません）、メンテナンスも簡単になります（テストステップの処理を直接記述できます）。
  • チェックの可視性: インタラクションはすべて、ユーザーから見えるエレメント上で発生します。たとえば、画像の後ろに隠れているボタンをタップしようとすると、テストは即座に失敗します。
  • 柔軟な設計: エレメントの選択、インタラクション、アサーション、同期を決定するコンポーネントは、拡張性のある設計となっています。
カップ 1 杯の EarlGrey で心機一転してみませんか？EarlGrey は、Apache ライセンスによるオープンソース ソフトウェアで、CocoaPods を使ってプロジェクトに追加することも、Xcode プロジェクト ファイルに手作業で追加することもできます。詳しくは、スタートガイドをご覧ください。

Posted by Khanh LeViet - Developer Relations Team