# REL08-BP02 デプロイの一部として機能テストを統合する
必要な機能を検証する単体テストや統合テストなどの技法を使用します。
ユニットテストは、コードの最小機能ユニットをテストして動作を検証するプロセスです。統合テストでは、各アプリケーション機能がソフトウェア要件に従って機能することを検証します。ユニットテストはアプリケーションの一部を個別にテストすることに重点を置いていますが、統合テストでは副作用 (例えば、ミューテーションオペレーションによってデータが変更された場合の影響) を考慮します。いずれの場合も、テストをデプロイパイプラインに統合する必要があり、成功基準を満たしていない場合、パイプラインは停止またはロールバックされます。このようなテストは、パイプラインの本稼働前にステージングされた、本稼働前環境で実行されます。
これらのテストがビルドおよびデプロイアクションの一部として自動的に実行されると、最良の結果が得られます。例えば、デベロッパーは AWS CodePipeline を使用して、CodePipeline が変更を自動的に検出するソースリポジトリに変更をコミットします。アプリケーションが構築され、ユニットテストが実行されます。ユニットテストが完了すると、ビルドされたコードがテスト用のステージングサーバーにデプロイされます。ステージングサーバーから、CodePipeline は統合やロードなどの色々なテストを実行します。これらのテストが正常に完了すると、CodePipeline はテストおよび承認されたコードを本番稼働インスタンスにデプロイします。
**期待される成果:** オートメーションを使用してユニットテストと統合テストを実行し、コードが期待どおりに動作することを確認します。これらのテストはデプロイプロセスに統合され、テスト失敗によりデプロイが中止されます。
**一般的なアンチパターン:**
+ デプロイのタイムラインを早めるために、デプロイプロセス中にテストの失敗や計画を無視またはバイパスする。
+ テストをデプロイパイプラインの外部で手動で実行する。
+ 手動の緊急ワークフローにより、自動化のテストステップを省略する。
+ 自動テストを、本番環境とあまり似ていない環境で実行する。
+ アプリケーションの進化に合わせて、柔軟性が低く、メンテナンス、更新、スケーリングが難しいテストスイートを構築する。
**このベストプラクティスを活用するメリット: **デプロイプロセス中の自動テストは問題を早期に検出するため、バグや予期しない動作で本番稼働にリリースされるリスクが軽減されます。ユニットテストでは、コードが目的どおりに動作し、API 契約が守られていることを確認します。統合テストでは、システムが指定された要件に従って動作することを検証します。これらのタイプのテストでは、ユーザーインターフェイス、API、データベース、ソースコードなどのコンポーネントの想定された動作順序を検証します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ソフトウェアの記述にはテスト駆動型の開発 (TDD) アプローチを採用し、コードを指定して検証するためのテストケースを開発します。開始するには、関数ごとにテストケースを作成します。テストが失敗した場合は、テストに合格するための新しいコードを記述します。このアプローチは、各関数の期待される結果を検証するのに役立ちます。ソースコードリポジトリにコードをコミットする前に、ユニットテストを実行し、合格することを確認します。
CI/CD パイプラインの構築、テスト、デプロイの各段階の一環として、ユニットテストと統合テストの両方を実装します。テストを自動化し、アプリケーションの新しいバージョンをデプロイする準備ができたら、テストを自動的に開始します。成功条件を満たさない場合、パイプラインは停止またはロールバックされます。
アプリケーションがウェブまたはモバイルアプリの場合は、複数のデスクトップブラウザまたは実際のデバイスで自動統合テストを実行します。このアプローチは、さまざまなデバイスにわたるモバイルアプリの互換性と機能を検証するのに特に役立ちます。
### 実装手順
1. 機能コード (*テスト駆動型の開発*、または TDD) を記述する前にユニットテストを記述します。ユニットテストの記述と実行が非機能的なコーディング要件となるように、コードガイドラインを確立します。
1. 識別されたテスト可能な機能をカバーする一連の自動統合テストを作成します。これらのテストでは、ユーザーインタラクションをシミュレートし、期待される結果を検証する必要があります。
1. 統合テストを実行するために必要なテスト環境を作成します。これには、本番環境を厳密に模倣するステージング環境または本番稼働前環境が含まれる場合があります。
1. AWS CodePipeline コンソールまたは AWS Command Line Interface (CLI) を使用して、ソース、ビルド、テスト、デプロイの各ステージを設定します。
1. コードの構築とテストが完了したら、アプリケーションをデプロイします。AWS CodeDeploy は、ステージング (テスト) 環境と本番環境にデプロイできます。これらの環境には、Amazon EC2 インスタンス、AWS Lambda 関数、またはオンプレミスサーバーが含まれる場合があります。アプリケーションをすべての環境にデプロイするには、同じデプロイメカニズムを使用する必要があります。
1. パイプラインの進行状況と各ステージのステータスをモニタリングします。品質チェックを使用して、テストのステータスに基づいてパイプラインをブロックします。パイプラインステージの障害や、パイプラインの完了に関する通知を受け取ることもできます。
1. テストの結果を継続的にモニタリングし、より注意が必要なパターン、リグレッション、または領域を探します。この情報を使用して、テストスイートを改善し、より堅牢なテストが必要なアプリケーションの領域を特定し、デプロイプロセスを最適化します。
## リソース
**関連するベストプラクティス:**
+ [REL07-BP04 ワークロードの負荷テストを実施する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_adapt_to_changes_load_tested_adapt.html)
+ [REL08-BP03 デプロイの一部として回復力テストを統合する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_resiliency_testing.html)
+ [REL12-BP04 カオスエンジニアリングを使用して回復力をテストする](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_failure_injection_resiliency.html)
**関連ドキュメント:**
+ [AWS 規範ガイダンス: テスト自動化](https://docs.aws.amazon.com/prescriptive-guidance/latest/performance-engineering-aws/test-automation.html)
+ [継続的デリバリーと継続的インテグレーション](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [機能テストのインジケータ](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/indicators-for-functional-testing.html)
+ [パイプラインのモニタリング](https://docs.aws.amazon.com/codepipeline/latest/userguide/monitoring.html)
+ [AWS CodeBuild で AWS CodePipeline を使用してコードをテストし、ビルドを実行する](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS Device Farm](https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-DeviceFarm.html)