翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
サーバーレスアプリケーションのテスト方法
サーバーレスアプリケーションコードに対してテストを実行するには、主にモックテスト、エミュレーションテスト、クラウドでのテストの 3 つのアプローチがあります。通常、1 つのプロジェクトでは、これら 3 つの方法が混在して使用されているはずです。たとえば、コードをローカルで開発する場合はモックテスト、デプロイ前のサービス動作をより厳密にレプリケートするエミュレーションテスト、夜間の継続的インテグレーションと継続的デリバリー (CI/CD) プロセスの一環としてクラウドテストを使用できます。
モックテスト
モックテストとは、コード内に、クラウドサービスの動作をシミュレートする代替オブジェクトを作成する戦略のことです。例えば、Amazon S3 サービスのモックを使用するテストを記述し、PutObjectメソッドが呼び出されるたびに特定のレスポンスオブジェクトを返すようにモックを設定できます。テストを実行すると、このモックは、Amazon S3 やその他のサービスエンドポイントを呼び出すことなく応答を返します。
これらの代替オブジェクトはモックのフレームワークによって生成されることが多く、所定のテストで必要とされる実装の量を減らします。モックフレームワークの中には汎用的なものもあれば、 AWS SDKs。
モックは、スタブとともに、フェイクのさらに広いカテゴリーに分類されます。モックは、エミュレータ (本セクションの後半で解説します) とは異なり、一般にデベロッパーによって、テストコードの一部として作成または設定されます。一方エミュレータは、エミュレート対象のシステムと同じ方法で API (REST API など) を公開する、スタンドアロンアプリケーションです。
モックを使用することのメリットは次のとおりです。
-
モックは、API や Software as a Service (SaaS) プロバイダーなど、アプリケーションの制御が及ばないサードパーティのサービスを、それらのサービスに直接アクセスすることなくシミュレートできます。
-
モックは障害状態、とりわけシミュレートが困難である状態 (サービスの停止など) のテストにも役立ちます。
-
エミュレータと同様に、モックフレームワークは設定後に迅速なローカル開発を提供できます。
-
モックは事実上あらゆる種類のオブジェクトの代替動作を提供できるため、モック戦略はエミュレータよりも幅広いサービスを対象とすることができます。
-
新しい機能や動作が利用可能になると、モックテストは一般的なモックフレームワークを使用して (またはそれにフォールバックして) より迅速に対応できます。モックフレームワークは、更新された AWS SDK が利用可能になるとすぐに新機能をシミュレートできます。
モックテストには次のような欠点があります。
-
モックは通常、特にレスポンスを適切に模倣するためにさまざまなサービスからの戻り値を特定しようとする際に、かなりの分量のセットアップや設定が必要になります。
-
モックは、テストを作成したデベロッパーが作成または設定するため、デベロッパーの責任が増えます。
-
サービスの API と戻り値を理解するため、場合によってはクラウドにアクセスする必要があります。
-
モックはメンテナンスが難しいこともあります。モックしたクラウド API の署名が変更されたり、戻り値のスキーマが進化したり、テスト対象のアプリケーションのロジックが拡張されて新しい API を呼び出したりするたびに、更新が必要になるためです。こうした変更は、デベロッパーのテスト開発の負担を増やします。
-
モックテストはローカルに合格するが、レプリケートするのではなく、実際のサービスの動作をシミュレートし、環境固有の問題が検出されないようにするため、クラウドで失敗する可能性があります。
-
エミュレータなどのモックフレームワークは、 AWS Identity and Access Management (IAM) ポリシー違反、サービスクォータ制限、ペイロードサイズの制約を検出することはできません。また、デプロイされた環境でのアプリケーション動作に影響を与える可能性のある Amazon CloudWatch AWS CloudTrail、Amazon GuardDuty などの補助サービスをトリガーすることもできません。
-
モックは、認可に失敗した場合やクォータを超えた場合にアプリケーションが何をするかをシミュレートするのに適していますが、モックテストでは、コードが本番環境にデプロイされたときに実際に発生する結果を判断できません。
エミュレーションテスト
エミュレーションテストは、 のようなエミュレータとして知られるローカルで実行されているアプリケーションによって有効になります AWS のサービス。エミュレータには、クラウド版と同様の戻り値を提供する API があります。また、API 呼び出しによって開始される状態変化をシミュレートすることもできます。例えば、Amazon S3 エミュレータは、 PutObjectメソッドが呼び出されたときにローカルディスクにオブジェクトを保存する場合があります。が同じキーで呼びGetObject出されると、エミュレータはディスクから同じオブジェクトを読み取り、返します。
エミュレーションテストには、以下のような利点があります。
-
エミュレーションテストの環境は、ローカル環境専用のコード開発に慣れているデベロッパーにとっては最も使いやすい環境です。例えば、n 層アプリケーションの開発に精通している場合は、本番稼働用と同様にデータベースエンジンとウェブサーバーをローカルマシンで実行して、迅速かつローカルで分離されたテスト機能を提供することができます。
-
クラウドインフラストラクチャ (デベロッパークラウドアカウントなど) に変更を加える必要がないため、既存のテストパターンで簡単に実装できます。エミュレーションテストには、ローカルでの開発の反復処理をすばやく実行できるという利点があります。
ただし、エミュレータにはいくつかの欠点があります。
-
特に CI/CD パイプラインの一部として使用する場合、セットアップとレプリケートが難しいことがよくあります。これにより、IT のスタッフや、ソフトウェアのインストールを自分で管理しているデベロッパーの、ワークロードとメンテナンスが増える可能性があります。
-
エミュレートされた機能や API はサービスの変更に後れを取るのが一般的で、サポートが追加されるまで新しい機能の導入が妨げられる可能性があります。
-
エミュレータには、サポート、更新、バグ修正、機能パリティの強化が必要になる場合がありますが、これらはエミュレータの作成者 (多くの場合サードパーティーの企業) が責任を負います。
-
エミュレータに依存するテストはローカルで成功する可能性がありますが、一般的にエミュレートされない IAM ポリシーやクォータ AWS など、 の他の側面とのやり取りが原因でクラウドで失敗する可能性があります。
-
一部の にはエミュレータ AWS のサービス が使用できないため、エミュレーションのみに依存する場合、アプリケーションの一部に対して十分なテストオプションがない可能性があります。
クラウドでのテスト
クラウドでのテストは、デスクトップ環境ではなくクラウド環境にデプロイされたコードに対して、テストを実行するプロセスです。クラウドでテストする価値は、クラウドネイティブなアプリケーションの開発で増大します。例えば、次のようになります。
-
最新の APIs とサービス機能に対してクラウドでテストを実行することで、 AWS 引き続き新しいサービスや機能を起動する際に、最新の戻り値と動作がテストに反映されるようにできます。
-
テストで、IAMポリシー、サービスクォータ、設定、すべてのサービスをカバーできます。
-
クラウドのテスト環境は、本番のランタイム環境に最も近いため、クラウドでテストを実行すると、環境の進化とともに最も一貫性のある結果を得られる可能性があります。
クラウドでのテストには、以下のような欠点があります。
-
クラウド環境へのデプロイは、通常、デスクトップ環境へのデプロイよりも時間がかかります。AWS Serverless Application Model (AWS SAM) Accelerate、AWS Cloud Development Kit (AWS CDK) watch mode、SST
といったツールを使用すると、クラウドでのデプロイのイテレーションに伴う遅延を減らすことができます。 -
クラウドのテストでは、ローカルの開発環境を使用するローカルテストとは異なり、サービスコストが追加で発生する場合があります。
-
高速インターネットアクセスがない場合、クラウドでのテストは実行可能性が低くなる可能性があります。
-
規制された業界では、エンタープライズセキュリティポリシーによって開発者のクラウド環境へのアクセスが制限され、ローカル開発ワークフローの一部としてクラウドテストを実行することが困難または不可能になる可能性があります。
-
環境の境界は、デベロッパー環境の共有アカウントではスタックレベルで引かれることが多く、プレフィックスを使用して所有権を特定するような、名前空間タイプの戦略が使用される場合もあります。本番稼働前環境と本番稼働環境では、一般にアカウントレベルで境界線が引かれます。これは、ノイズの多い近隣の問題からワークロードを隔離し、最小特権のセキュリティコントロールをサポートし、機密データを保護するためです。隔離された環境を作成する要件は、特にアカウントとインフラストラクチャを厳密に制御する企業に属している場合、DevOps チームに追加の負担がかかる可能性があります。
