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