統合テストとは何か-ユニットと比較して
プロジェクトで単体テストを使用し始め、メソッド/関数レベルでテストするテストを作成しています。
私はこれを理解し、それは理にかなっています。
しかし、統合テストとは何ですか？私が読んだものから、それはテストの範囲をアプリケーションのより大きな機能をテストすることに移します。
これは、（eコマースサイトで）チェックアウト機能、ユーザーログイン機能、バスケット機能などのより大きなものをテストするための新しいテストスイートを作成することを意味します。だからここで私は3つの統合テストを書いたでしょうか？
これは正しいですか-そうでない場合、誰かが何を意味するのか説明できません。
また、統合テストにはui（ここではWebアプリケーションコンテキスト）が含まれ、Seleniumのようなものを使用して自動化します。または、統合テストはまだコードレベルで行われていますが、異なるクラスとコードの領域を結び付けています。
このようなメソッドを考えてみましょうPerformPayment(double amount, PaymentService service);
単体テストは、service引数のモックを作成するテストです。
統合テストは、実際の外部サービスを使用して、そのサービスが入力データに正しく応答するかどうかをテストするテストです。
ユニットテストは、テストされたコードが実際のクラスの中にあるテストです。フォーカスがコードをテストするため、このクラスの別の依存関係はモックまたは無視されますinsideクラス。
統合テストは、ディスクアクセス、アプリケーションサービス、フレームワークターゲットアプリケーションからを含むテストです。統合テストは、別の外部サービスからisolatedを実行します。
例を挙げましょう。 Springアプリケーションがあり、ビジネスロジックが適切に動作していることを保証するために多数の単体テストを行いました。完璧です。しかし、どのような種類のテストを保証する必要がありますか：
- アプリケーションサービスを開始できます
- データベースエンティティが正しくマッピングされている
- 必要なすべての注釈が期待どおりに機能している
- フィルターは正しく機能しています
- APIが何らかのデータを受け入れています
- あなたの主な機能は本当に基本的なシナリオで機能しています
- データベースクエリは期待どおりに機能しています
- 等...
これは単体テストでは実行できませんが、開発者はすべてのものが正常に機能していることを保証する必要があります。これが統合テストの目的です。
理想的なシナリオは、アプリケーションが本番環境で使用する別の外部システムから独立して実行される統合テストです。これは、Wiremock for Rest呼び出し、H2のようなメモリデータベース、外部システムを呼び出す特定のクラスのBeanのモックなどを使用して実現できます。
Mavenには少し興味がありますが、統合テスト用の特定のプラグイン：maven failsafe pluginは、名前が[〜＃〜] it [〜＃〜]で終わるテストクラスを実行します。例：UserIT.Java。
統合テストの意味についての混乱
一部の人々は、「統合テスト」を、現在システムが使用している他の外部システムへの「統合」を伴うテストとして理解しています。この種のテストは、あなたが出席するためにシステムが稼働しているallがある環境でのみ実行できます。何も偽物も、何もからかわない。
これは名前付けの問題にすぎないかもしれませんが、上記の項目の必要性に対応するテスト（統合テストとして理解しているもの）が不足しています。逆に、ユニットテスト（テストクラスのみ）の定義を「統合」テスト（実際のシステム全体）にジャンプします。では、統合テストでなければ、その真ん中に何があるのでしょうか？
この混乱の詳細については、Martin Fowlerの この記事 を参照してください。彼は、「統合テスト」という用語を2つの意味で区別します。「広範な」統合テストと「狭い」統合テストです。
狭い統合テスト
- 別のサービスと通信する私のサービスのコードの部分のみを行使する
- プロセス内またはリモートで、これらのサービスのテストダブルを使用します
- したがって、多くの場合、範囲が限定された多くのテストで構成され、多くの場合、範囲はユニットテストよりも大きくありません（通常、単体テストに使用されるのと同じテストフレームワークで実行されます）。
広範な統合テスト
- すべてのサービスのライブバージョンが必要であり、実質的なテスト環境とネットワークアクセスが必要
- 対話を担当するコードだけでなく、すべてのサービスを通じてコードパスを実行する
ユニットテストは、クラスまたはコードの一部内でビジネスロジックをテストする場所です。たとえば、メソッドの特定のセクションがリポジトリを呼び出す必要があることをテストしている場合、ユニットテストは、リポジトリを呼び出すインターフェースのメソッドが期待される正しい回数呼び出されていることを確認するためにチェックし、そうでない場合は失敗しますテスト。
一方、統合テストは、実際のサービスまたはリポジトリ（データベース）の動作が正しいことをテストします。これは、渡したデータに基づいて、予期した結果を取得することを確認しています。これはユニットテストと連携しているため、取得する必要があるデータと、そのデータで何が行われるかがわかります。
次に、優れた単体テストが満たす2つの制約を示します。これらの制約を満たすには、テスト可能な優れたコードも必要でした。
- I/Oなし-ディスクまたはネットワーク
- 1つのアサーションのみ（複数の場合、それらは互いにマイナーバリエーションである必要があります）
- それが主張するよりもはるかに多くの量産コードを実行（カバー）しない
これらの制約は通常、統合テストには適用されません。
私が見る限り、Seleniumテストは別のテストスイートにあるはずです。これらのテストは、正しく記述した場合でも、本質的に最も壊れやすいテストです。ここでは、サンプルフレームワークによるSpecflowまたは他の種類の仕様を使用できます。おそらく、これらのテストを受け入れテストと呼ぶことができます。これらは、開発者やビジネスの専門家も対象です。統合、またはモジュールのテストは通常、UIを使用しません。統合テストは、一緒に機能するいくつかのクラスを実行します。これらはSeleniumテストよりも低レベルのテストであり、保守が少し簡単です。これらのテストは開発者専用です。