UI Automator：その概要、主要概念、動作方法

UI Automatorとは？

UI Automatorは、オペレーティングシステムレベルで動作するAndroidの機能UIテストのためのフレームワークです。デバイス画面の任意の要素にアクセスするためのAPIを提供し、それがどのアプリに属しているかに関係なく — システムステータスバー、権限ダイアログ、ホーム画面、サードパーティアプリを含みます。これにより、単一アプリを超えるシナリオのテストに不可欠です。

アーキテクチャ的には、UI AutomatorはAccessibility Serviceを使用します — TalkBack、Switch Access、その他のアクセシビリティツールが使用する同じサービスです。このサービスを通じて、フレームワークは現在の画面の完全なUIコンポーネントツリーを取得し、タップ、スワイプ、テキスト入力、長押しなどのアクションを実行できます。

UI AutomatorはAndroid 4.3（API 18）で初めて登場し、それ以来、クロスアプリケーションテストのためのGoogleの公式ツールとしてAndroid Testing Support Libraryの一部です。AndroidX Testでは、個別のアーティファクトandroidx.test.uiautomator:uiautomatorバージョン2.3.0（2024）として利用可能で、API 18以降のすべてのAndroidバージョンをサポートしています。

UI Automatorの仕組み

動作原理： UI Automatorは、現在の画面のアクセシビリティツリーをスキャンすることに基づいています。findObject(selector)メソッドが呼び出されると、フレームワークはView階層を走査し、UiSelector条件に一致する最初の要素を見つけ、UiObject — 実際のViewと対話するためのプロキシを返します。

UI Automatorテストのライフサイクル

典型的なUI Automatorテストは、物理デバイスを表すUiDeviceインスタンスを取得することから始まります。UiDeviceは、要素の検索、ボタン押下（ホーム、バック、最近）の管理、画面の回転、スクリーンショットの取得のためのメソッドを提供します。UiSelectorを介して要素を見つけた後、UiObjectに対してアクションが実行されます。

基本的な例

以下の例では、テストが設定アプリを開き、テキストで“バッテリー”項目を見つけてタップします。UI AutomatorはActivityの起動を必要としません — サードパーティアプリを含むデバイスの任意の画面で動作します。

val device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation())

// 設定画面を開く
device.pressHome()
device.wait(Until.hasObject(UiSelector().text("設定")), 2000)

// "バッテリー"項目を探してタップ
val batteryItem = device.findObject(
    UiSelector().text("バッテリー")
)
batteryItem.clickAndWait(Until.newWindow(), 3000)

UiDeviceとUiSelector：主要クラス

UiDeviceはデバイスと対話するためのメインクラスです。要素の検索、ハードウェアボタン押下（ホーム、バック、メニュー、音量）のシミュレーション、電力管理、スクリーンショットの取得、特定の画面状態の待機のためのメソッドを提供します。UiDeviceはテストごとに1回作成され、すべての操作で再利用されます。

UiSelectorはUI要素を検索するためのfluent APIです。Espresso ViewMatchersとは異なり、UiSelectorはコンパイルを必要としません — 検索条件はメソッドチェーンを通じて形成されます：text()、className()、description()、resourceId()、index()。複数の条件は論理ANDを介して自動的に結合されます。

複数条件での検索例

画面上に同じテキストを持つ複数の要素がある場合、UiSelectorは基準を組み合わせることができます：IDでコンテナを見つけ、その中で — テキストとクラスで要素を見つけます。これにより、目的のコンポーネントの一意の識別が保証されます。childSelectorメソッドは検索範囲を指定されたコンテナに絞り込み、UIツリーのナビゲーションを高速化します。

val scrollView = device.findObject(
    UiSelector().resourceId("android:id/list")
)

// リスト内でテキスト"Wi-Fi"の要素を探す
val wifiItem = scrollView.findObject(
    UiSelector().text("Wi-Fi")
wifiItem.click()

UI Automatorによるクロスアプリケーションテスト

クロスアプリケーション（アプリ間）テストは、UI Automatorが選ばれる主な機能です。フレームワークはアプリ間を切り替え、ブラウザを介したOAuthログインをテストし、システムダイアログ（権限、アプリ選択）を確認し、システムステータスバー、通知パネル、ロック画面と対話できます。

OAuthログインテスト

典型的なクロスアプリテストシナリオ：アプリがOAuth認証のためにブラウザを開き、ユーザーがログインとパスワードを入力し、ブラウザがアプリにリダイレクトします。UI Automatorはプロセス間を切り替え、ブラウザの入力フィールドを見つけ、入力して“サインイン”をタップします。

// ブラウザの表示を待機
device.wait(Until.hasObject(
    UiSelector().packageName("com.android.chrome")
), 5000)

// ブラウザでメール入力フィールドを検索
val emailField = device.findObject(
    UiSelector().className("android.widget.EditText").instance(0)
)
emailField.text = "user@example.com"

システムダイアログの確認

UI Automatorはシステムダイアログを確認して閉じることができます — 位置情報の権限、通知、ファイルアクセス。これは、システムが複数の権限を順次要求する初回起動シナリオのテストにとって極めて重要です。UI Automatorがなければ、システムダイアログはアプリのプロセスに属さないため、これらのシナリオを自動化することはできません。

UI Automator vs Espresso：アプローチの比較

選択はテストシナリオによって異なります。Espressoは、自動同期と最小限のボイラープレートで単一アプリをテストするために最適化されています。UI Automatorは、システム、ブラウザ、または複数のアプリと対話する必要があるシナリオに適しています。

実際には、これらのフレームワークは一緒に使用されることがよくあります：Espressoは高い安定性でメインアプリのUIテストをカバーし、UI Automatorはアプリの境界を超えるシナリオ — OAuthログイン、システム権限、Share Intentの操作に使用されます。この組み合わせにより、最小限のテスト保守コストで最大のUIカバレッジが得られます。

AndroidプロジェクトでのUI Automatorのセットアップ

統合は、build.gradleに依存関係を追加することで行われます。フレームワークはAndroidX Testの一部であり、マニフェストに追加の権限は必要ありません — インストゥルメンテッドテストが起動されると、Accessibility Serviceへのアクセスが自動的に設定されます。

Gradle依存関係

最小構成には、uiautomatorアーティファクトと標準のAndroidJUnitRunnerテストランナーが含まれます。UI Automatorテストはsrc/androidTestディレクトリに配置され、Android API 18+を実行するエミュレータまたは物理デバイスで実行されます。

dependencies {
    androidTestImplementation("androidx.test.uiautomator:uiautomator:2.3.0")
    androidTestImplementation("androidx.test.ext:junit:1.2.1")
    androidTestImplementation("androidx.test:runner:1.6.1")
}

UiDeviceとテスト設定

UiDeviceインスタンスを取得するには、InstrumentationRegistry.getInstrumentation()を使用します。UiDeviceはsetUp()メソッドで一度作成し、デバイスリソースを節約するためにクラスのすべてのテストで再利用する必要があります。UiDeviceはスレッドセーフではないことに注意することが重要です — すべての操作はテストメソッドの同じスレッドで実行する必要があります。各テストで新しいUiDeviceを作成すると、オーバーヘッドが発生し、実行が遅くなります。beforeClassメソッドで一度UiDeviceを作成し、テストクラスのすべてのテストで再利用することをお勧めします。

UI Automatorでの待機

Espressoとは異なり、UI Automatorには自動同期がありません。要素の表示を待機するには、UiDevice.wait(condition, timeout)メソッドをUntilオブジェクトとともに使用します：Until.findObject(selector)、Until.hasObject(selector)、Until.gone(selector)。適切な待機がないと、競合状態のためにテストが不安定になります — 検索時に要素が画面に表示されていない可能性があります。安定性のために、少なくとも3〜5秒のタイムアウトを設定することをお勧めします。