Java での統合テストの概要

1. 統合テストの概要
2. 統合テストの重要性
3. 統合テストの種類
4. 統合テストに必要な手順

このチュートリアルでは、統合テストを紹介し、それを単体テストと区別する方法を強調します。 さらに、長所と短所を考慮して、さまざまな種類の統合テストについて説明します。

次に、統合テストを実行するために必要な手順について学習し、続いて統合テストを理解するための実際のシナリオを学習します。

統合テストの概要

テスト ピラミッド には、単体テスト、統合テスト、機能テストの 3 種類のテストがあります。 この記事では、統合テストを中心に展開します。つまり、さまざまなモジュールをグループとして組み合わせたときに、それらが期待どおりに機能するかどうかを確認します。

ソフトウェアは、複数のプログラマーがコーディングしたさまざまなモジュールで構成されていることを思い出してください。 ここで、統合テストの主な目的は、2つまたは複数のソフトウェア モジュールを論理的に統合し、それらをグループとしてテストすることによって、それらの間のインターフェイスをテストすることです。

さらに、さまざまなソフトウェア コンポーネントを統合するときに、それらの間の相互作用の欠陥を明らかにすることで、インターフェイスの正確性を判断します。 すべてのソフトウェア コンポーネントの単体テストが完了すると、統合テスト プロセスが開始されます。

単体テストと統合テストを視覚化するには、以下を参照してください。

以下は、統合テストが単体テストとどのように異なるかを強調するためのいくつかのポイントです。

詳しくは こちら をご覧ください。

統合テストの重要性

すべてのソフトウェア コンポーネントは単体テストされていますが、さまざまな理由で欠陥が明らかになる可能性があるため、統合テストの重要性が増しています。 それらのいくつかを以下に示します。

1. ソフトウェアモジュールのより良い統合を可能にします。
2. 統合テストを使用することで、ソフトウェア モジュールの転送中のデータの変更を防ぐことができます。
3. 手動テストのさまざまな問題も解決します。
4. 統合テストは、効果的なサードパーティ テストも可能にします。
5. すべてのソフトウェア コンポーネントが 1つのユニットで動作し、期待どおりの出力を生成することを確認する必要があります。
6. 外部ハードウェア インターフェイスおよびソフトウェア モジュールのデータベースとのインターフェイスの欠陥を見つけることは有用です。
7. クライアントは、ソフトウェア モジュールの開発中に要件を変更することがあります。 その場合、新しい要件が単体テスト レベルでテストされない可能性があります。 したがって、ここでは統合テストが不可欠になります。

統合テストの種類

この記事では、長所と短所を考慮して、統合テストの 2つのアプローチについて説明します。

1. ビッグバン
2. インクリメンタル（さらにトップダウン、ボトムアップ、サンドイッチ アプローチに分類）

統合テストのためのビッグバンアプローチ

このアプローチでは、すべてのソフトウェア コンポーネントを統合して、テスト中にエンティティと呼ばれるユニットとしてテストします。 この統合プロセスは、単体テストのすべてのコンポーネントが完了するまで実行されません。

システムテストと混同しないでください。 システム全体ではなく、さまざまなソフトウェア モジュールの統合のみをテストします (システム テストで実行)。

その最大の利点は、すべてのソフトウェア コンポーネントを統合して 1つのユニットとしてテストできることですが、ビッグバン アプローチを使用して欠陥を特定することも困難です。 したがって、すべての小規模システムに便利です。

ビッグバン アプローチを次のように視覚化できます。 6つの異なるモジュールを統合し、ビッグバンを使用してテストしました。

統合テストの漸進的アプローチ

このアプローチを使用して、相互に論理的に関連する 2つ以上のソフトウェア モジュールを統合し、アプリケーションが適切に機能するかどうかをテストします。 次に、他の関連モジュール/コンポーネントが段階的に統合され、テストされます。

この手順は、論理的に関連するすべてのコンポーネントが統合されてテストされるまで続きます。

このアプローチは、さらにトップダウン、ボトムアップ、およびサンドイッチ アプローチに分類されます。 Stubs と Drivers を通して、それぞれについて以下で学びましょう。

1. スタブ - テスト中のモジュール/コンポーネントによって呼び出されます。
2. Driver - モジュール/コンポーネントをテストする必要があります。

トップダウンアプローチ

ここでは、統合はソフトウェア システムの制御フローに従って上から下に実行されます。 このアプローチを使用して、上位レベルのコンポーネントをテストしてから、下位レベルのコンポーネントに移動してソフトウェアの機能を確認します。

ここで、一部のコンポーネントがまだ読み取られていない場合は、Stubs を使用できます。 これは、実際の環境で起こることと一致する有機的な方法です。

このアプローチのもう 1つの利点は、重要なモジュールを優先的にテストできることです。 このようにして、より高いレベルで欠陥を見つけて、最初に修正することができます。

一方、このアプローチでは、主要な機能を最後にテストすることが唯一の懸念事項です。 次の図でそれを視覚化できます。

ボトムアップアプローチ

ここでは、最初に下位レベルのモジュールをテストします。これは、上位レベルのモジュールのテストを支援するために使用されます。 この手順は、最上位ですべてのモジュール/コンポーネントをテストするまで続きます。

ボトムアップのアプローチでは、ドライバーとして知られる刺激プログラムを使用します。 下位レベルの欠陥やエラーを見つけるのは簡単ですが、上位レベルの問題は、すべてのコンポーネントが統合されてテストされて初めて発見できます。

サンドイッチアプローチ

このアプローチは、トップダウンとボトムアップのアプローチを組み合わせたものであるため、ハイブリッド統合テストとして知られています。 スタブ と ドライバー を使用します。

ここでは、トップレベルのコンポーネントが下位レベルのコンポーネントでテストされます。 同時に、下位のコンポーネント/モジュールが最上位のモジュール/コンポーネントと統合され、システムとしてテストされます。

このアプローチを次のように視覚化できます。

統合テストに必要な手順

どのようなソフトウェア テスト戦略 (上記で説明) が使用されているかに関係なく、次の手順が必要です。

統合テストを理解するための実例

performPayment() というメソッドがあるとします。このメソッドは、2つのパラメーター mount と service の double 型と PaymentService をそれぞれ受け取ります。

単体テストでは、service 引数のモックを作成してテストしますが、統合テストは、実際の外部 service を使用して、その service が入力データに応答するかどうかを確認するテストになります。 予想通り。