テストすべき内容は、アプリのタイプ、開発チーム、レガシーコードの量、使用されているアーキテクチャなどの要因によって異なります。以下のセクションでは、初心者がアプリでのテストを計画する際に考慮すべき点を概説します。
テスト ディレクトリの編成
Android Studio の一般的なプロジェクトには、実行環境に応じてテストを保持する 2 つのディレクトリがあります。次のように、テストを次のディレクトリに整理します。
androidTestディレクトリには、実際のデバイスまたは仮想デバイスで実行するテストを含める必要があります。このようなテストには、統合テストやエンドツーエンド テストのほか、JVM だけではアプリの機能を検証できないテストが含まれます。testディレクトリには、ローカルマシンで実行するテスト（単体テストなど）を格納する必要があります。上記とは対照的に、これらはローカル JVM で実行するテストです。
重要な単体テスト
ベスト プラクティスに従う場合は、次のような場合に単体テストを使用してください。
- ViewModel（プレゼンター）の単体テスト。
- データレイヤ（特にリポジトリ）の単体テスト。データレイヤーのほとんどはプラットフォームに依存しないものにする必要があります。これにより、テストダブルで、テストのデータベース モジュールとリモート データソースを置き換えることができます。Android でテストダブルを使用する方法についてのガイドをご覧ください。
- ドメインレイヤなど、他のプラットフォームに依存しないレイヤの単体テスト（ユースケースやインタラクタなど）。
- 文字列操作や数学などのユーティリティ クラスの単体テスト。
エッジケースのテスト
単体テストは、通常ケースとエッジケースの両方に焦点を当てる必要があります。エッジケースは、人間のテスターや大規模なテストでは検出できないまれなシナリオです。以下に例を示します。
- 負の数、ゼロ、境界条件を使用する数学演算。
- 考えられるすべてのネットワーク接続エラー。
- 不正な形式の JSON など、データが破損している。
- ファイルへの保存時にストレージの空き容量不足をシミュレートします。
- プロセスの途中で再作成されるオブジェクト（デバイスが回転されたときのアクティビティなど）。
避けるべき単体テスト
一部の単体テストは、値が低いため避けてください。
- コードではなく、フレームワークまたはライブラリの正常な動作を検証するテスト。
- アクティビティ、フラグメント、サービスなどのフレームワークのエントリ ポイントにはビジネス ロジックを持たせないため、単体テストを優先すべきではありません。アクティビティの単体テストは、ほとんどがフレームワーク コードをカバーし、より複雑なセットアップが必要になるため、ほとんど価値がありません。UI テストなどのインストルメンテーション テストは、これらのクラスに対応しています。
UI テスト
採用すべき UI テストには、次のようなものがあります。
- 画面 UI テスト: 重要なユーザー インタラクションを 1 つの画面でチェックします。ボタンのクリック、フォームへの入力、表示状態の確認などのアクションを実行します。最初に画面ごとに 1 つのテストクラスを用意することをおすすめします。
- 最も一般的なパスを対象とするユーザーフロー テストまたはナビゲーション テスト。これらのテストは、ユーザーがナビゲーション フローを移動する場合をシミュレートします。これはシンプルなテストであり、初期化時の実行時のクラッシュを確認する際に役立ちます。
その他のテスト
スクリーンショット テスト、パフォーマンス テスト、Monkey テストなど、より専門的なテストがあります。回帰、ユーザー補助機能、互換性などの目的別にテストを分類することもできます。
参考資料
単独でテストするには、テスト対象の依存関係を、一般的に「テストダブル」と呼ばれる疑似またはモックの依存関係に置き換える必要があります。詳しくは、Android でテストダブルを使用するをご覧ください。
単体テストや UI テストの作成方法について詳しくは、テストの Codelab をご覧ください。