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

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

以下のセクションでは、クラウドテストの戦略を実装するときに遭遇するさまざまな課題について概説します。

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

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

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

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

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

Amazon SQS 統合をシミュレートするローカルテストでは、特定のペイロードで Amazon SQS から呼び出されたとき Lambda 関数がどのような動作をするかが検証されますが、クラウド環境にデプロイされたときに Amazon SQS が Lambda 関数を呼び出せるかどうかは検証されません。

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

• Amazon SQS の可視性タイムアウトが短すぎるため、意図された 1 回のみの呼び出しが複数回発生する。

• Lambda 関数の実行ロールが、キュー (sqs:ReceiveMessage、sqs:DeleteMessage、sqs:GetQueueAttributes を経由) からのメッセージの読み取りを許可しない。

• Lambda 関数に渡されるサンプルイベントが Amazon SQS メッセージサイズクォータを超えている。したがって、Amazon SQS ではそのサイズのメッセージは送信できず、テストが無効になる。

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