テストの観点からサーバーレスアプリケーションのワークフローを再考する

フェーズ1：要件

アーキテクチャ概要

• AWS LambdaとStep Functionsを使用したバッチ処理ワークフロー。
• 3つのステートが直線状に並ぶ。
• 各Lambda関数にはユニットテストがあるが、Step Functionsのワークフローは手動でテストする。

テストの目標

• Step Functionsのワークフローテストを自動化する。
• 入力値と出力値が期待値に一致することを確認する。
• GitHub Actionsを使用して、テストをCI/CDパイプラインに統合する。
• テストのために実際のAWS環境へデプロイすることを避ける。

フェーズ2：計画

ツールと技術

• Step Functions Local：Step Functionsをローカルで実行、テストする。
• GitHub Actions：CI/CDワークフローを自動化する。
• LocalStackなど：AWS Lambdaをローカルでシミュレーションする。

GitHub Actionsのワークフロー

• プッシュまたはプルリクエスト時にテストを実行するワークフローを設定する。
• ローカルテスト環境にはStep Functions LocalのDockerイメージを使用する。
• LambdaのシミュレーションにはLocalStackを使用する。
• https://www.localstack.cloud/
• Step Functionsの定義をインポートし、ワークフローをローカルで実行する。
• 各ステートの入力値と出力値を検証する。

ワークフローの手順

• [ 1 ] コンテナの起動：
• Step Functions LocalのDockerイメージを取得して起動する。
• Lambdaのシミュレーション用にLocalStackを設定する。
• [ 2 ] Step Functions定義のインポート：
• ステートマシンの定義をローカル環境へインポートする。
• [ 3 ] ワークフローの実行：
• ローカルエンドポイントを使用してStep Functionsのワークフローをトリガーする。
• [ 4 ] 結果の検証：
• 入力値と出力値を期待値と照合する。
• [ 5 ] 結果の報告：
• テストの成功または失敗を示すレポートやステータスを生成する。

サーバーレスアーキテクチャをどうテストするか

はじめに

• サーバーレスアーキテクチャには大きな利点があり、顧客へ価値を迅速に提供できる。
• ここでは、システムの性能やコストではなく、テストの観点に焦点を当てる。

なぜテストが必要なのか

• テストは、システムの挙動を理解、予測、制御するために役立つ。
• システムのリスクを特定し、定量化できる。
• テストを書くことで、要件をより深く理解できる。
• テストにより、結果の再現性と説明可能性を確保できる。
• テストの主な目的は、未知のリスクを減らすこと。

テストの種類

• ユニットテスト：個々のコンポーネントや関数を分離してテストする。
• 統合テスト：組み合わせたコンポーネント間の連携をテストする。
• ロジックテスト：ビジネスロジックの正しさを検証する。
• ワークフローテスト：プロセスやワークフローの最初から最後までの流れをテストする。
• APIテスト：APIの機能と信頼性をテストする。

推奨事項

• テストの種類ごとの目的と目標を意識することが重要。
• これらのテストの種類を理解すると、サーバーレスアーキテクチャに効果的なテスト戦略を設計しやすくなる。

テストを容易にするための処理の分離

要点

• テストしやすい単位：テストしやすい単位は、理解もしやすい。
• システムの明確さ：システムを分離されたテスト可能な単位で設計すると、何を、いつ、なぜ行うのかが自然と明確になる。
• 複雑さの回避：テストが難しい場合、1か所に責務とロジックが集中しすぎている可能性が高い。

例の比較

• 不十分なアーキテクチャ：1つのLambda関数が、他のサーバーからのデータ取得と、DynamoDBへのデータ処理／保存の両方を担う。
• 適切なアーキテクチャ：処理ごと（データ取得、データの処理／保存）にLambda関数を分離する。

分離の利点

• 各部分を個別にテストしやすくなる。
• エラーが発生したとき、問題の正確な位置を特定しやすくなる。
• エラーの発生から特定、修正までの時間を短縮できる。

一般原則

• メソッドの分割：メソッドを分割するという同じ原則は、さまざまなプログラミング言語（Python、Ruby、Goなど）に適用できる。
• 小さな単位：何を小さなテスト可能単位とするかを特定し、それに応じて分割の原則を適用する。

システム設計におけるテストの観点

• 弱点の特定：テストの観点から見ると、1か所に責務が集中しすぎているといった弱点を特定しやすい。
• エラー検出時間の短縮：テスト容易性が高いと、開発サイクルの短縮と同様に、エラーの発生から検出、修正までの時間を短縮できる。
• 迅速な提供：テスト容易性が高いほど、システムを迅速に提供できる。

テストの観点からサーバーレスアーキテクチャを構築する際の要点

• 処理の分離：テストしやすい単位は理解しやすい。処理を分離すると弱点を特定しやすくなり、エラー検出までの時間を短縮できる。
• 複雑さの回避：1か所に責務とロジックが集中すると、テストが難しくなる。処理を分離し、テストとトラブルシューティングを簡素化する。
• 高いテスト容易性：システムの迅速な提供と開発サイクルの短縮に貢献する。

最終目標

• エンジニアの究極の目標は、ユーザーへ価値を提供すること。
• 成果につなげるため、常にユーザー価値を意識する。
• 知見を共有してテスト手法を改善するため、議論と協力を促進する。