デベロッパードキュメントガイドテストの基本ユーザーは、ボタンの押下からデバイスへの情報のダウンロードまで、さまざまなレベルでアプリを操作します。したがって、アプリの反復型開発を行う過程で、さまざまなユースケースとインタラクションをテストする必要があります。インターフェースをレンダリングするなどの処理が必要になることがあります。アプリを多様な用途で使用するには、包括的なテスト戦略が必要です。コードの作成とテストを反復的に行う機能の反復型開発を行う場合は、新しいテストを作成するか、または既存の単体テスト(ユニットテスト)にケースとアサーションを追加することから始めます。機能がまだ実装されていないため、最初はテストがエラーになります。新しい機能に影響するユニットを考慮することは重要です。したユニットは機能の設計段階でわかってきます。ユニットごとに、対応する単体テストを作成します。単体テストでは、標準的な操作、無効な入力、リソースが利用できない場合の処理など、ユニットについて考えられるすべてのインタラクションをできる限りテストする必要があります。ライブラリを活用してください。十分にテストが行われたライブラリですから、うまく利用することでアプリの個別の動作の検証に専念できます。示すワークフローの全体図には、入れ子構造になった反復サイクルが示されています。中心のテストサイクルでは、コードユニットの統合をテストします。比較的早く期間の短い開発サイクルでは、ユニットそのもののテストを行います。このような一連のサイクルは、アプリがすべてのユースケースでテストに合格するまで続きます。アプリを一連のモジュールとして見るコードのテストを容易にするには、モジュールの観点に立ってコードを開発します。各モジュールは、ユーザーがアプリ内で実行する特定のタスクを表すものと考えます。ロジック、データに対応するレイヤで構成されたものとして捉えることの多い、スタックベースの視点とは対照的です。アプリの場合、タスクの作成、完了したタスクに関する統計の表示、特定のタスクに関連付けられる写真の撮影を行うモジュールなどが考えられます。このようなモジュール型のアーキテクチャを採用することで、関連のないクラスを分離した状態に保つことができ、開発チーム内でのオーナー権限の割り当てが行いやすい構造になります。各モジュールの間に明確に定義された境界を設定し、アプリの規模と複雑さの進展に合わせて、新しいモジュールを作成していくことが重要です。一貫性を確保する必要があります。モジュール間のインタラクションを簡単かつ迅速にテストするため、モジュールの仮の実装を作成することを検討してください。テストでは、実際に実装するモジュールから、他のモジュールの仮の実装を呼び出すことができます。新しいモジュールを作成する際には、完全な機能の短期間での実現にこだわる必要はありません。つないし複数なくても特に問題はありません。アプリバンドルをご覧ください。テスト環境を構成するアプリでテストを作成するための環境と依存関係をセットアップする際は、このセクションで説明するおすすめの方法に従ってください。次のようにテストを配置してください。ディレクトリには、実際のデバイスまたは仮想デバイスで実行するテストを配置します。アプリの機能を検証できない場合のテストがあります。ディレクトリには、単体テストなど、ローカルマシンで実行するテストを配置します。さまざまなタイプのデバイスでテストを実行する場合のトレードオフを検討するデバイスでテストを実行する場合、次のタイプのデバイスを選択できます。)再現性が最も高いのは実際のデバイスですが、テストの実行に時間がかかります。シミュレートされたデバイスでは、テスト速度は向上しますが、再現性が低下します。レベルでのプラットフォームの改善や、現実的なループの採用により、シミュレートされたデバイスでもより実際に近い結果が再現できます。仮想デバイスでは、再現性とテスト速度のバランスを適度に保つことができます。仮想デバイスでテストする場合は、スナップショットを使用すると、テスト間でのセットアップ時間を最小限に抑えられます。オブジェクト)を作成する方法があります。一般的には、実際のオブジェクトをテストで使用する方がテストダブルを使用するよりも適切です。テスト対象のオブジェクトが次の条件のいずれかに当てはまる場合は特にそうです。オブジェクトが実際の依存関係のオブジェクトと通信しないと機能しない。ハンドラが挙げられます。オブジェクトの依存関係との接続を複製することが困難。ハンドラが挙げられます。データベースを使用する方が、テストの確実性が増します。自分が管理していない型のインスタンスのモックを作成する場合は、テストが不確実なものになりがちです。他人による型の実装を正確に把握しないと、テストがうまくいかないからです。このようなモックの使用は、最後の手段としてください。アノテーションを付けたモックの方が再現性が高いことに留意してください。オブジェクトを作成することをおすすめします。大きなファイルの処理など、時間のかかるオペレーション。任意のオープン状態のポートへの接続など、隔離されていないアクション。作成するのが難しい構成。インフラストラクチャ(仮のオブジェクトなど)が提供されているか確認してください。テストを作成するテスト環境を構成し終えたら、アプリの機能を評価するテストを作成します。このセクションでは、小規模テスト、中規模テスト、大規模テストの作成方法について説明します。)について、アプリで扱うべき程度を示しています。つのクラスごとにアプリの動作を検証する単体テストです。中規模テストは、モジュール内のスタックレベルでのインタラクション、または関連するモジュール間のインタラクションを検証する統合テストです。小規模テストから大規模テストへとピラミッドの段階が上がるにつれて、各テストの再現性は向上しますが、実行時間と保守およびデバッグの労力が増大します。テストより統合テストを増やす必要があります。割合でテストを作成することをおすすめします。秒以降)をご覧ください。小規模テストを作成する小規模テストは、対象を絞り込んだ単体テストとし、アプリ内の各クラスの機能とコントラクトを徹底的に検証する必要があります。クラス内のメソッドの追加または変更を行った場合、該当箇所に対する単体テストを作成して実行します。このように一貫した対応をとることで、物理デバイスやエミュレータを使用することなく、ローカルでテストを実行できます。オプションを有効にします。これにより、単体テストでリソースのコンパイル済みバージョンを利用できるようになるため、迅速かつ正確にテストを実行できます。以上では、デフォルトでリソースのコンパイル済みバージョンが提供されます。