サーバーレスアプリケーションのテスト方法

サーバーレスアプリケーションのコードに対してテストを実行する方法には、主としてモックテスト、クラウドでのテスト、エミュレーションテストの 3 つの方法があります。通常、1 つのプロジェクトでは、これら 3 つの方法が混在して使用されているはずです。例えば、コードをローカルで開発するときはモックテストを使用し、夜間の継続的インテグレーションと継続的デリバリー (CI/CD) プロセスの一環である場合にはクラウドでテストするといったようにです。

モックテスト

モックテストとは、コード内に、クラウドサービスの動作をシミュレートする代替オブジェクトを作成する戦略のことです。例えば、Amazon S3 サービスのモックを使用するテストを作成する場合、CreateObject メソッドが呼び出されるたびに特定の応答オブジェクトを返すようにモックを設定します。テストを実行すると、このモックは、Amazon S3 やその他のサービスエンドポイントを呼び出すことなく応答を返します。

これらの代替オブジェクトはモックのフレームワークによって生成されることが多く、所定のテストで必要とされる実装の量を減らします。モックフレームワークの中には汎用的なものもあれば、 AWS SDKs 専用に設計されたものもあります。

モックは、スタブとともに、フェイクのさらに広いカテゴリーに分類されます。モックは、エミュレータ (本セクションの後半で解説します) とは異なり、一般にデベロッパーによって、テストコードの一部として作成または設定されます。一方エミュレータは、エミュレート対象のシステムと同じ方法で API (REST API など) を公開する、スタンドアロンアプリケーションです。

モックを使用することのメリットは次のとおりです。

• モックは、API や Software as a Service (SaaS) プロバイダーなど、アプリケーションの制御が及ばないサードパーティのサービスを、それらのサービスに直接アクセスすることなくシミュレートできます。

• モックは障害状態、とりわけシミュレートが困難である状態 (サービスの停止など) のテストにも役立ちます。

• エミュレータと同様、モックのフレームワークは、設定後にローカルでの迅速な開発を可能にします。

• モックは事実上あらゆる種類のオブジェクトの代替動作を提供できるため、モック戦略はエミュレータよりも幅広いサービスを対象とすることができます。

• 新しい機能や動作が利用可能になると、モックテストは汎用モックフレームワークを使用して (またはフォールバックして) より迅速に対応できます。モックフレームワークは、更新された AWS SDK が利用可能になるとすぐに新機能をシミュレートできます。

モックテストには次のような欠点があります。

• モックは通常、特にレスポンスを適切に模倣するためにさまざまなサービスからの戻り値を特定しようとする際に、かなりの分量のセットアップや設定が必要になります。

• モックは、テストを作成したデベロッパーが作成または設定するため、デベロッパーの責任が増えます。

• サービスの API と戻り値を理解するため、場合によってはクラウドにアクセスする必要があります。

• モックはメンテナンスが難しいこともあります。モックしたクラウド API の署名が変更されたり、戻り値のスキーマが進化したり、テスト対象のアプリケーションのロジックが拡張されて新しい API を呼び出したりするたびに、更新が必要になるためです。こうした変更は、デベロッパーのテスト開発の負担を増やします。

• モックテストは、デスクトップ環境では合格してもクラウドでは失敗する場合があります。

• エミュレータなどのモックフレームワークは、テストまたは検出 AWS Identity and Access Management (IAM) ポリシーまたはクォータの制限があります。

• 認可に失敗したりクォータを超過したりしたときの、アプリケーションの動作をシミュレーションするには、モックの方が適していますが、モックテストでは、コードを本番環境にデプロイしたとき実際にどのような結果になるのかを判定することはできません。

クラウドでのテスト

クラウドでのテストは、デスクトップ環境ではなくクラウド環境にデプロイされたコードに対して、テストを実行するプロセスです。クラウドでテストする価値は、クラウドネイティブなアプリケーションの開発で増大します。以下に例を示します。

• クラウドでのテストは、最新の API や戻り値に対して行うことができます。

• テストで、IAMポリシー、サービスクォータ、設定、すべてのサービスをカバーできます。

• クラウドのテスト環境は、本番のランタイム環境に最も近いため、クラウドでテストを実行すると、環境の進化とともに最も一貫性のある結果を得られる可能性があります。

クラウドでのテストには、以下のような欠点があります。

• クラウド環境へのデプロイは、通常、デスクトップ環境へのデプロイよりも時間がかかります。AWS Serverless Application Model (AWS SAM) Accelerate、AWS Cloud Development Kit (AWS CDK) watch mode、SST といったツールを使用すると、クラウドでのデプロイのイテレーションに伴う遅延を減らすことができます。

• クラウドのテストでは、ローカルの開発環境を使用するローカルテストとは異なり、サービスコストが追加で発生する場合があります。

• 高速のインターネットアクセスを使用できない場合、クラウドでのテストを実行できる可能性は低いかもしれません。

• クラウドでのテストには、通常、互いに分離されたクラウド環境が必要です。環境の境界は、デベロッパー環境の共有アカウントではスタックレベルで引かれることが多く、プレフィックスを使用して所有権を特定するような、名前空間タイプの戦略が使用される場合もあります。本番稼働前環境と本番稼働環境では、一般にアカウントレベルで境界線が引かれます。これは、ノイズの多い近隣の問題からワークロードを隔離し、最小特権のセキュリティコントロールをサポートし、機密データを保護するためです。隔離された環境を作成するという要件は、特にアカウントとインフラストラクチャを厳しく管理している企業では、DevOps チームにさらなる負担をかける可能性があります。

エミュレーションテスト

エミュレータテストは、 AWS サービスに似たエミュレータと呼ばれるローカルで実行されるアプリケーションによって有効になります。エミュレータには、クラウド版と同様の戻り値を提供する API があります。また、API 呼び出しによって開始される状態変化をシミュレートすることもできます。例えば、Amazon S3 エミュレータは、PutObject メソッドが呼び出されたとき、オブジェクトをローカルディスクに保存する場合があります。GetObject が同じキーで呼び出されると、エミュレータは同じオブジェクトをディスクから読み取り、これを返します。

エミュレーションテストには、以下のような利点があります。

• エミュレーションテストの環境は、ローカル環境専用のコード開発に慣れているデベロッパーにとっては最も使いやすい環境です。例えば、n 層アプリケーションの開発に慣れていれば、本番環境で実行されているものと同様のデータベースエンジンとウェブサーバーをローカルマシン上で実行して、高速かつ隔離されたテスト機能をローカルで提供できる可能性があります。

• クラウドインフラストラクチャ (デベロッパーのクラウドアカウントなど) を変更する必要がないため、既存のテストパターンで簡単に実装できます。エミュレーションテストには、ローカルでの開発の反復処理をすばやく実行できるという利点があります。

ただし、エミュレータにはいくつかの欠点があります。

• 特に CI/CD パイプラインの一部として使用する場合、設定や複製が行えないことがよくあります。これにより、IT のスタッフや、ソフトウェアのインストールを自分で管理しているデベロッパーの、ワークロードとメンテナンスが増える可能性があります。

• エミュレートされた機能や API はサービスの変更に後れを取るのが一般的で、サポートが追加されるまで新しい機能の導入が妨げられる可能性があります。

• エミュレータには、サポート、更新、バグ修正、機能パリティの強化が必要になる場合がありますが、これらはエミュレータの作成者 (多くの場合サードパーティーの企業) が責任を負います。

• エミュレータに依存するテストは、ローカルで成功した結果を提供できますが、通常はエミュレートされない IAM ポリシーやクォータ AWS など、 の他の側面とのやり取りが原因でクラウドで失敗する可能性があります。

• 一部の AWS サービスにはエミュレータがないため、エミュレーションのみに依存している場合、アプリケーションの一部に対して十分なテストオプションがない可能性があります。