アプリの開発において、テストは非常に重要なプロセスです。通常、エミュレータまたはデバイスでアプリを実行して、コードが想定どおりに動作することを手動で確認します。ただし、手動テストは時間がかかり、エラーが発生しやすいため、さまざまなサイズの画面やデバイスで実行されるアプリでは管理が困難な場合があります。手動テストの問題は、多くの場合、開発に単一のデバイスを使用している結果です。その結果、フォーム ファクタが異なる他のデバイスではエラーが検知されない可能性があります。
さまざまなウィンドウと画面サイズでの回帰を特定するには、自動テストを実装して、さまざまなフォーム ファクタでアプリの動作と外観が一貫していることを確認します。自動テストでは問題を早期に特定できるため、ユーザー エクスペリエンスに影響するリスクを軽減できます。
テスト項目
さまざまな画面サイズとウィンドウサイズ向けの UI を開発する場合は、次の 2 つの点に特に注意してください。
- サイズの異なるウィンドウでコンポーネントとレイアウトの視覚的属性がどのように異なるか
- 構成変更後も状態が保持される仕組み
視覚的属性
さまざまなウィンドウ サイズに合わせて UI をカスタマイズするかどうかにかかわらず、UI が正しく表示されることを確認する必要があります。幅と高さは、コンパクト、中程度、拡張のいずれかになります。推奨されるブレークポイントについては、ウィンドウ サイズクラスをご覧ください。
また、サイズ制約が引き伸ばされると、デザインシステムの一部のコンポーネントが想定どおりにレンダリングされない可能性があります。
アプリにさまざまなウィンドウ サイズに対応するアダプティブ レイアウトがある場合は、回帰を防ぐためにテストを自動化する必要があります。たとえば、スマートフォンで余白を固定すると、タブレットでレイアウトの不整合が生じる可能性があります。UI テストを作成してレイアウトとコンポーネントの動作を確認するか、スクリーンショット テストを作成してレイアウトを視覚的に確認します。
状態の復元
タブレットなどのデバイスで実行されるアプリは、スマートフォンのアプリよりも回転とサイズ変更が頻繁に行われます。また、折りたたみ式デバイスには、折りたたみや開くなどの新しいディスプレイ機能が導入されており、構成の変更をトリガーする可能性があります。アプリは、これらの構成変更が発生したときに状態を復元できる必要があります。また、アプリの状態が正しく復元されることを確認するテストも作成する必要があります。
まず、構成変更の発生時にアプリがクラッシュしないことを確認します。アプリ内のすべての UI が、回転、サイズ変更、折りたたみの組み合わせを処理できるようにします。構成を変更すると、デフォルトでアクティビティが再作成されるため、アクティビティの永続性を前提としてクラッシュが発生することがあります。
構成変更をテストする方法は複数ありますが、ほとんどの場合、次の 2 つの方法があります。
- Compose では、
StateRestorationTesterを使用して、アクティビティを再起動せずに構成変更を効率的にシミュレートします。詳しくは、以下のセクションをご覧ください。 - Espresso や Compose などの UI テストでは、
Activity.recreate()を呼び出して構成変更をシミュレートします。
通常、構成変更に応じた状態の復元をテストするために別のデバイスを使用する必要はありません。これは、アクティビティを再作成するすべての構成変更に同様の影響があるためです。ただし、一部の構成変更により、特定のデバイスで異なる状態復元メカニズムがトリガーされる場合があります。
たとえば、ユーザーが開いた折りたたみ式デバイスでリスト詳細 UI を表示していて、デバイスを折りたたんでフロント ディスプレイに切り替えると、通常、UI は詳細ページに切り替わります。自動テストでは、ナビゲーション状態を含む UI 状態の復元を対象とする必要があります。
デバイス間でのディスプレイの切り替え、またはマルチウィンドウ モードへの切り替え時に発生する構成変更をテストするには、複数の方法があります。
- 任意のデバイスを使用して、テスト中に画面のサイズを変更します。ほとんどの場合、これにより、検証する必要があるすべての状態復元メカニズムがトリガーされます。ただし、折りたたみ式デバイスの特定の形状を検出するロジックでは、形状の変化によって構成の変更がトリガーされないため、このテストは機能しません。
- テストする機能をサポートするデバイスまたはエミュレータを使用して、関連する構成変更をトリガーします。たとえば、折りたたみ式デバイスやタブレットを Espresso デバイスを使用して制御し、横向きで折りたたみ状態からオープンフラット状態に移行できます。例については、さまざまな画面サイズをテストするためのライブラリとツールの Espresso Device セクションをご覧ください。
さまざまな画面サイズとウィンドウサイズのテストタイプ
ユースケースごとに適切なタイプのテストを使用して、さまざまなフォーム ファクタでテストが正しく動作していることを確認します。
UI 動作テストは、アクティビティの表示など、アプリ UI の一部を起動します。テストでは、特定の要素が存在すること、または特定の属性を持つことを確認します。テストでは、必要に応じてシミュレートされたユーザー アクションを実行することがあります。ビューの場合は Espresso を使用します。Jetpack Compose には独自のテスト API があります。UI 動作テストは、インストルメンテーションまたはローカルに行うことができます。インストルメンテーション テストはデバイスまたはエミュレータで実行されますが、ローカル UI テストは JVM の Robolectric で実行されます。
UI 動作テストを使用して、アプリのナビゲーションの実装が正しいことを確認します。テストでは、クリックやスワイプなどのアクションを実行します。UI 動作テストでは、特定の要素やプロパティの存在も確認します。詳細については、UI テストを自動化するをご覧ください。
スクリーンショット テストでは、UI またはコンポーネントのスクリーンショットを取得し、画像を以前に承認されたスクリーンショットと比較します。1 つのスクリーンショットで多数の要素とその視覚プロパティをカバーできるため、これは回帰を防ぐ非常に効果的な方法です。スクリーンショット テストは、JVM またはデバイスで実行できます。複数のスクリーンショット テスト フレームワークが用意されています。詳細については、スクリーンショット テストをご覧ください。
最後に、デバイスの種類やウィンドウサイズに応じて動作が異なるロジック単位の機能をテストするために単体テストが必要になる場合がありますが、この分野では単体テストはあまり一般的ではありません。
次のステップ
このドキュメントに記載されているチェックを実装する方法について詳しくは、ライブラリとツールをご覧ください。