アプリの開発において、テストは非常に重要なプロセスです。通常は、エミュレータまたはデバイスでアプリを実行して、コードが期待どおりに動作するかを手動で確認します。しかし、手動テストは時間がかかり、エラーが発生しやすくなります。また、さまざまなサイズの画面やデバイスで実行されるアプリでは管理が困難です。手動テストの問題はほとんどの場合、開発に 1 台のデバイスを使用することが原因です。その結果、フォーム ファクタが異なる他のデバイスではエラーに気づかない可能性があります。
さまざまなウィンドウと画面サイズでの回帰を特定するには、自動テストを実装して、アプリの動作と外観がさまざまなフォーム ファクタで一貫していることを確認します。自動テストは早い段階で問題を特定し、ユーザー エクスペリエンスに影響を与える問題のリスクを軽減します。
テスト項目
さまざまな画面サイズとウィンドウ サイズ用に 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 またはデバイスで実行できます。スクリーンショットのテスト フレームワークは複数用意されています。
最後に、デバイスの種類やウィンドウ サイズによって動作が異なるロジックの機能をテストする単体テストが必要になることもありますが、この分野では単体テストがあまり一般的ではありません。
次のステップ
このドキュメントに含まれているチェックの実装方法について詳しくは、ライブラリとツールをご覧ください。