翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

サーバーレスアプリケーションをテストする際の課題

エミュレータとモック呼び出しを使ってローカルのデスクトップでサーバーレスアプリケーションをテストすると、コードが CI/CD パイプラインの環境間を移動したときにテストの不整合が生じることがあります。アプリケーションのビジネスロジックを検証するためにデスクトップで作成するユニットテストには、クラウドサービスの重要な側面が含まれていないか、正確に表現されていない可能性があります。完全なテストは、個別にローカルで実行することはできません。完全なテストを行うには、複数のサービス間でアクセス許可や構成を検証することが必要になります。

以下のセクションでは、クラウドテストの戦略を実装するときに遭遇するさまざまな課題について概説します。以下のセクションでは、クラウドテスト戦略を実装する際にお客様が経験する課題と、効果的なテストカバレッジを達成するためのベストプラクティスに関するガイダンスの概要を説明します。

例: Amazon S3 バケットを作成する Lambda 関数

Lambda 関数のロジックが Amazon S3 バケットの作成に依存している場合、完全なテストでは、Amazon S3 が正常に呼び出され、バケットが正常に作成されたことを確認する必要があります。モックテストの設定では、成功レスポンスをモックし、失敗レスポンスを処理するテストケースを追加することもあります。エミュレーションテストシナリオでは、CreateBucketAPI が呼び出される場合がありますが、呼び出しを行う ID はロールを引き受ける Lambda サービスから発信されるのではなく、代わりにプレースホルダー認証が使用されます。これは多くの場合、より寛容なロールまたはユーザー ID です。

以前に解説したモックとエミュレーションのセットアップでは、Amazon S3 の呼び出しに成功 (または失敗) した場合に Lambda 関数がどのような動作をするかが検証されます。ただし、これらのテストでは、関数の設定によっては、Lambda 関数がバケットを正常に作成できるかどうかをキャプチャできません。この設定は AWS CloudFormation、 AWS SAMや HashiCorp Terraform などの製品やサービスのコードとしてのインフラストラクチャ (IaC) によって表される可能性があります。 HashiCorp 考えられる問題の 1 つは、関数に割り当てられたロールに s3:CreateBucketアクションを許可するポリシーがアタッチされていないことです。そのため、関数はクラウド環境にデプロイされると常に失敗します。

例: Amazon SQS からのメッセージを処理する Lambda 関数

Amazon Simple Queue Service (Amazon SQS) キューが Lambda 関数のソースである場合、完全なテストでは、メッセージがキューに入れられたときに Lambda 関数が正常に呼び出されたことを確認する必要があります。エミュレーションテストとモックテストは通常、Lambda 関数コードを直接実行し、JSON イベントペイロード (または逆シリアル化されたオブジェクト) を関数ハンドラーの入力として渡すことで Amazon SQS 統合をシミュレートするように設定されます。

Amazon SQS 統合をシミュレートするローカルテストでは、特定のペイロードで Amazon SQS によって呼び出されたときに Lambda 関数が何をするかがテストされますが、クラウド環境にデプロイされたときに Amazon SQS が Lambda 関数を正常に呼び出すことは保証されません。

Amazon SQS と Lambda で発生する可能性のある設定の問題として、次のような例があります。

これらの例が示すように、ビジネスロジックは対象とするがクラウドサービス間の構成は対象としないテストでは、信頼性の低い結果が得られる可能性があります。