ウェブ アプリケーションのバックエンドのテストは、開発プロセスや継続的なモニタリングにおいて重要です。フロントエンドのテストもご覧ください。
テストドリブンな開発
テストドリブン開発（TDD）では、アプリケーションを完全に実装する前にアプリケーションの要件をテストケースに変換します。開発時には、これらのテストが最初に作成され、アプリがビルドされるにつれて継続的に実装されます。明確な要件（テストケースなど）を設けることで、最終的なコードが適切に構造化され、すべての要件を満たし、正確であることを確認できます。これは開発の初期段階で特に重要です。
継続的インテグレーションと自動テスト
継続的インテグレーション（CI）テストでは、コードレビュー時やコード リポジトリへのマージ時など、コードの変更に対してテストが自動的に実行されます。自動テストにより、開発中の破損やリグレッションのリスクを軽減することで、送信されるコードの全体的な品質と信頼性を向上させることができます。アプリケーションの健全性を確保するために、環境に自動テストシステムを設定することをおすすめします。アーキテクチャ、プラットフォーム、言語によってサポートされ、開発パイプラインにシームレスに統合されたシステムを使用できます。たとえば、CI ワークフロー用の GitHub Actions や、構成に合わせてカスタマイズされたクラウドに組み込まれたカスタム CI パイプラインを使用します。
自動テストの原理とテストの改善方法についての詳細をご覧ください。継続的インテグレーション テストの詳細と、成功の実装、設定、測定のベスト プラクティスを確認する。
次のステップとして、アプリケーションの変更と更新を自動的にデプロイする自動継続的デリバリー（CD）パイプラインを検討してください。
単体テスト
単体テストとは、コードの自己完結型の小さな部分を個別にテストすることです。バックエンドの言語またはフレームワークで推奨され、よく使われている単体テスト フレームワークを使用します。たとえば、Java ベースのモノリシック アプリケーションの場合は JUnit を使用し、JavaScript ベースのサーバーレス アプリケーション（Dart や TypeScript など）の場合は、JavaScript テスト用に構築されたフレームワーク（Jest など）を使用します。
最新のバックエンド フレームワークのほとんどには、テスト用の専用リソースがあります。これらの機能を CI パイプラインに統合して、テストを自動化することを検討してください。単体テストでアプリのコード カバレッジが適切であることを確認します。ほとんどのテスト フレームワークには、テスト カバレッジを分析して報告し、ビルド パイプラインに統合できる機能が用意されています。
統合テスト
統合テストとは、より大きなモジュールやアプリの一部を同時にテストすることです。単体テストは（コードの個々の部分に焦点を当てます）、統合テストは、アーキテクチャの個々の部分の統合に重点を置きます。これには、アプリ内の複数のステップとモジュールを対象とするエンドツーエンドのフローも含まれる場合があります。
統合テストは、データ ストレージ、ファイルシステム、支払いなどの外部サービスとのやり取りを必要とするアプリのさまざまなモジュールを対象としている場合があります。依存関係インジェクションまたはバックエンド フレームワークから提供される同様の機能を通じて、これらのサービスの抽象化をサポートするようにアプリケーションを構造化することを検討してください。
動作と機能のテスト
機能テストは、バックエンド（または個々のモジュールやコンポーネント）に不透明なボックスとしてアクセスし、システムの入力と出力に重点を置きます。動作テストは、フロントエンドでは一般的ですが、バックエンド システムのエンドツーエンドの整合性を確認する際にも重要な役割を果たします。この種のテストでは、システムがさまざまな入力に対して想定どおりに反応して動作することを確認します。
回帰テスト
回帰テストとは、アプリが引き続き想定どおりに動作することを確認するテストのことです。以前に正常に完了したテストが再実行されて新しい変更があり、変更によって以前の問題が再導入されていないことが確認されます。アプリのバグが修正されたら、単体テストまたは統合テストを追加して、バグが再発しないようにする必要があります。回帰テストは、通常のテストとビルドのパイプラインに統合する必要があります。
スモークテスト
スモークテストはビルド検証テストとも呼ばれ、バックエンド アプリケーションの特に重要な機能の検証に重点を置いています。スモークテストでは、一部の機能と外部依存関係を抽象化する統合テストを超えて、アプリケーションの重要なユースケースをカバーします。スモークテストは、アプリがステージング環境に昇格する前に追加の検証レイヤとして機能し、正確な動作を確認できます。スモークテストには、自動化された単体テストと、QA チームによる手動の機能テストがあります。
本番環境とステージング環境
ステージング環境は本番環境のコピーであり、テストを容易にするためにサンドボックス化されています。専用のデプロイにより、本番環境に関する問題のリスクを軽減し、品質保証を簡単に実施できます。ステージング環境では、実際の本番環境に近いシステムをテストできます。
コストやバックエンド アーキテクチャの複雑さなどの要因により、本番環境のコピーを 1 対 1 で作成できない場合があります。バックエンドのどの部分が最も重要かを検討し、それらをステージング環境向けに最適化します。
本番環境で使用されるデータに対してテストを行うことは、実際のデータに対するアプリの挙動をテストするための大きなメリットです。このようなステージング環境では、プライバシーへの影響とデータ ストレージのニーズを考慮し、バックエンド システムで使用するデータを慎重に設計してください。このような環境へのアクセスは、特に本番環境データが使用されている場合は、厳密に制御する必要があります。
システムの規模と、アプリケーションに適した持続環境を検討してください。継続的デリバリー システムによって自動的にデプロイできるローリング ステージング環境では、毎日または毎週のビルドをテストし、リリース前に追加の調査を行うこともできます。
もう 1 つのアプローチは、完全にデプロイされたステージング環境ではなく、継続的インテグレーション テストと自動システムを使用することです。チームのワークフロー、システムの健全性、コード カバレッジ、技術要件を考慮してください。