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

# でのサーバーレスアプリケーションのテスト AWS
<a name="introduction"></a>

*アマゾン ウェブ サービス* (寄[寄稿者](contributors.md)稿者)

*2026 年* 3 月 ([ドキュメント履歴](doc-history.md))

本ガイドでは、サーバーレスアプリケーションのテスト方法について解説し、テスト中に発生する問題について説明し、ベストプラクティスについてご紹介します。ご紹介するテストテクニックは、これまでよりも迅速に反復処理を行い、確信をもってコードをリリースできるようにすることを目指しています。

本ガイドは、サーバーレスアプリケーション用の、テスト戦略の作成を目指すデベロッパーを対象としています。始めに本ガイドを読み、テスト戦略について理解できたら、次は「[Serverless Test Samples repository](https://github.com/aws-samples/serverless-test-samples)」へお進みください。本ガイドでご紹介したパターンやベストプラクティスに沿うテストの例をご覧いただけます。このガイドでは、サーバーレステストの方法論について説明し、サーバーレスアプリケーションをテストする際にお客様が直面する課題について説明し、サーバーレスアプリケーションをテストするためのベストプラクティスを紹介します。これらの手法は、デベロッパーがより迅速に反復処理し、より自信を持ってリリースできるようにすることを目的としています。

## 概要:
<a name="overview"></a>

自動テストへの投資は、アプリケーションの質と開発スピードを確保するために欠かせません。テストを行えば、デベロッパーもフィードバックをしやすくなります。デベロッパーなら、アプリケーションの反復処理をすばやく行って、コードの質に関するフィードバックを集めたいと考えるはずです。デベロッパーの多くは、アプリケーションを、自分のデスクトップ環境で (オペレーティングシステムに直接、あるいはコンテナベースの環境内に) デプロイし、作成することに慣れています。デスクトップまたはコンテナベースの環境で作業すると、通常は、そのデスクトップで完全にホストされたコードに対してテストを作成することになります。一方、サーバーレスアプリケーションの場合は、デスクトップ環境にデプロイできず、クラウドにしか存在できないアーキテクチャコンポーネントが含まれることがあります。クラウドベースのアーキテクチャには、永続化レイヤー、メッセージングシステム、セキュリティコンストラクト、APIs、およびその他のコンポーネントが含まれる場合があります。こうしたコンポーネントに依存するアプリケーションコードを作成するときは、テストを設計し実行する最適な方法をみきわめることが、難しくなる場合があります。

本ガイドを読めば、摩擦や混乱を減らすテスト戦略に従い、コードの質を高めることができます。

## 前提条件
<a name="prerequisites"></a>

本ガイドの内容は、ソフトウェアの質を確保する自動ソフトウェアテストの実行方法など、自動テストの基本を理解していることが前提条件となります。このガイドでは、サーバーレスアプリケーションテスト戦略の概要を説明しており、テストの記述に関する実践的な経験は必要ありません。

## 定義
<a name="definitions"></a>

本ガイドでは、以下の用語を使用します。
+ *ユニットテスト*は、1 つのアーキテクチャコンポーネントのコードに対して、隔離して実行されるテストです。
+ *統合テスト*** **は、通常はクラウド環境で、2 つ以上のアーキテクチャコンポーネントに対して実行されます。
+ *End-to-endのテスト*では、アプリケーションまたはワークフロー全体の動作を検証します。
+ *エミュレータ*は、クラウドリソースをプロビジョニングまたは呼び出すことなくクラウドサービスを模倣するように設計されたアプリケーション (多くの場合、サードパーティーから提供されます) です。
+ *モック* (フェイクともいいます) は、依存関係をそのシミュレーションに置き換える、テストアプリケーションの実装のことです。

## 目的
<a name="business-outcomes"></a>

本ガイドのベストプラクティスは、主に次の 2 つの目的を達成することを目指しています。
+ サーバーレスアプリケーションの質を高める
  + アーキテクチャの境界でのテスト
  + コード境界でのテスト
+ 機能の実装や変更にかかる時間を短縮する

### ソフトウェアの質を高める
<a name="increase-software-quality"></a>

アプリケーションの品質は、開発者がさまざまなシナリオをテストして機能を検証する能力に大きく依存します。自動テストを実装しない場合、またはより一般的には、テストが必要なシナリオを適切にカバーしていない場合、アプリケーションの品質を決定または保証することはできません。

サーバーベースのアーキテクチャの場合、チームは、テストすべき範囲を容易に規定することができます。アプリケーションサーバーで実行されるコードをすべてテストすればよいからです。それ以外の、サーバーを呼び出すコンポーネントや、サーバーが呼び出す依存関係などは、サーバーのアプリケーションを担当しているチームから無関係とみなされ、テストの範囲から外されることがよく起こります。

サーバーレスアプリケーションは、多くの場合、 AWS Lambda 関数のように、独自の環境で実行している小さな作業単位で構成されています。チームはこうした、1 つのアプリケーションの中にある、より小さな単位を複数担当することになります。アプリケーションの機能の中には、内部で開発されたコードを一切使用せずに、Amazon Simple Storage Service (Amazon S3) や Amazon Simple Queue Service (Amazon SQS) といったマネージドサービスに完全に委ねることができるものもあります。従来のサーバーベースのソフトウェアテストでは、マネージドサービスは、アプリケーションとは無関係とみなされて除外されることがあります。除外されるとテスト範囲が不十分になり、重要なシナリオが、手動での探索的テストや環境によって結果が変わる少数の統合テストのケースなどに限られる可能性があります。したがって、マネージドサービスの動作とクラウド構成までを含めたテスト戦略を採用すれば、ソフトウェアの質を高めることができるのです。

#### アーキテクチャの境界でのテスト
<a name="testing-at-architecture-boundaries"></a>

サーバーレスアプリケーションは成長するにつれて、複数のアーキテクチャコンポーネントに自然に分散します。これは AWS 分散機能を使用しますが、end-to-endの動作を理解するのが難しい場合があります。

##### 自然境界の特定
<a name="identifying-natural-boundaries"></a>

サーバーレスのベストプラクティス (1 つの関数 = 1 つのジョブ、デカップリング) に従ってアーキテクチャを設計すると、サブシステムの自然な境界に気付くでしょう。これらの境界は、アプリケーションの論理的な分離ポイントを表します。

##### テスト契約としての境界
<a name="boundaries-as-testing-contracts"></a>

これらのアーキテクチャの境界は、エッジをテストするための優れた候補です。各境界を契約として扱い、定義された仕様に従って動作することを確認します。これらの境界は、テスト検証を挿入できるアプリケーションの*継ぎ*目と考えてください。

##### 主な利点
<a name="key-benefits"></a>

以下は、アーキテクチャの境界でテストする主な利点です。
+ **重点テストスコープ** – アプリケーション全体を理解することなく、サブシステムを個別にテストします。
+ **契約の検証** - システムが進化するにつれて、各境界が期待される動作を維持していることを確認します。
+ **二用途計測** – これらの同じ境界により、本番環境で優れたオブザーバビリティフックになります。
+ **テストハーネス **– 非同期サーバーレスシステムをテストできます。これは、サブシステムを通過するイベントをキャプチャして検証することで、イベント駆動型アーキテクチャをテストするのに役立ちます。

#### コード境界でのテスト
<a name="testing-at-code-boundaries"></a>

Lambda コードなどのインフラストラクチャコードをコアビジネスロジックから分離して、明確なコードの境界を定義します。この分離により、テスト戦略を簡素化する個別のテストスコープが作成されます。

##### 境界パターン
<a name="the-boundary-pattern"></a>

Lambda 関数に 2 つの明確なコード境界を確立します。
+ **外部境界 (Lambda ハンドラー)** – 固有の懸念を処理するスリムなアダプターレイヤー AWS Lambda
+ **内部境界 (ビジネスロジック)** – Lambda ランタイムから独立した純粋なビジネスロジックメソッド

##### アダプターとしてのハンドラー (外部スコープ)
<a name="handler-as-adapter"></a>

Lambda 関数ハンドラーは、次の薄いレイヤーである必要があります。
+ 受信オブジェクト`event`と `context` オブジェクトからデータを抽出します。
+ 抽出されたデータを検証します
+ 関連する詳細のみをビジネスロジックメソッドに渡します
+ Lambda に期待される形式で結果を返します

##### ビジネスロジック (内部スコープ)
<a name="business-logic"></a>

コアビジネスロジックは次の条件を満たす必要があります。
+ Lambda に固有の詳細とは無関係に運用する
+ シンプルで検証済みの入力を受け入れる
+ 予測可能な出力を返す
+ 初期化に最小限の依存関係が必要

##### スコープ別のテストの利点
<a name="testing-benefits-by-scope"></a>
+ **内部境界テスト** – Lambda の複雑さや環境設定のないビジネスロジックに関する包括的なユニットテスト
+ **外部境界テスト** – アダプターレイヤーのイベント処理とデータ抽出を検証する集中統合テスト
+ **最小限のテストオーバーヘッド** – テストの大部分に複雑な環境や広範な依存関係は必要ありません。

この境界ベースのアプローチにより、Lambda テストを最小限に抑えながら、ほとんどのコードを純粋な関数としてテストできます。

### 機能の実装や変更にかかる時間を短縮する
<a name="decrease-time-to-implement-or-change-features"></a>

反復的な開発サイクル中にこれらの問題をキャッチすることで、ソフトウェアバグや設定の問題がコストやスケジュールに与える影響を最小限に抑えることができます。開発者がこれらの問題を検出できなかった場合、より多くの人が問題を特定するために追加の労力を費やす必要があります。

サーバーレスアーキテクチャには、API 呼び出しを通じて重要なアプリケーション機能を提供するマネージドサービスが含まれていることがあります。このため、開発サイクルには、*ハッピーパス* (これらのサービスとのやり取りが期待どおりに動作する) と*悲しいパス* (呼び出しが失敗する、予期しない応答を返す、または環境間で異なる動作をする) の両方を検証するテストを含める必要があります。これらのテストを実施しないと、ローカル環境とデプロイされた環境の違いに起因する問題が発生する可能性があります。この場合、修正の再現と検証にさらに時間を費やす必要があります。これは、各反復で、希望するセットアップとは異なる環境に対する変更の検証が必要になるようになったためです。

適切なサーバーレステストの戦略を使用すれば、他のサービスの呼び出しを含め正確な結果が得られるため、反復処理の時間を短縮することができます。