統合テスト

デプロイをアプリケーションサーバーに要求したり、他のエンタープライズインフラストラクチャに接続したりすることなく、いくつかの統合テストを実行できることが重要です。そうすることで、次のようなことをテストできます。

  • Spring IoC コンテナーコンテキストの正しい接続。

  • JDBC または ORM ツールを使用したデータアクセス。これには、SQL ステートメントの正確性、Hibernate クエリ、JPA エンティティマッピングなどが含まれます。

Spring Framework は、spring-test モジュールでの統合テストに対する最上級のサポートを提供します。実際の JAR ファイルの名前にはリリースバージョンが含まれている場合があり、入手先によっては長い org.springframework.test 形式になる場合もあります (説明については、依存関係管理のセクションを参照してください)。このライブラリには、Spring コンテナーとの統合テスト用の貴重なクラスが含まれる org.springframework.test パッケージが含まれています。このテストは、アプリケーションサーバーや他の デプロイ環境に依存しません。このようなテストの実行は単体テストよりも遅くなりますが、アプリケーションサーバーへの デプロイに依存する同等の Selenium テストや リモートテストよりははるかに高速です。

ユニットおよび統合テストのサポートは、アノテーション駆動型 Spring TestContext フレームワークの形式で提供されます。TestContext フレームワークは、使用中の実際のテストフレームワークにとらわれないため、JUnit、TestNG などを含むさまざまな環境でのテストの計測が可能です。

次のセクションでは、Spring の統合サポートの高レベルのゴールの概要を説明し、この章の残りの部分では、専用のトピックに焦点を当てます。

統合テストのゴール

Spring の統合テストサポートの主なゴールは次のとおりです。

次のいくつかのセクションでは、各ゴールについて説明し、実装と構成の詳細へのリンクを提供します。

コンテキスト管理とキャッシュ

Spring TestContext フレームワークは、Spring ApplicationContext インスタンスと WebApplicationContext インスタンスの一貫したロード、およびこれらのコンテキストのキャッシングを提供します。Spring 自体のオーバーヘッドではなく、Spring コンテナーによってインスタンス化されたオブジェクトのインスタンス化に時間がかかるため、起動時間が課題になる可能性があるため、ロードされたコンテキストのキャッシュのサポートが重要です。例: Hibernate マッピングファイルが 50 から 100 のプロジェクトでは、マッピングファイルの読み込みに 10 から 20 秒かかる場合があり、すべてのテストフィクスチャですべてのテストを実行する前にそのコストが発生すると、全体的なテスト実行が遅くなり、開発者の生産性が低下します。

通常、テストクラスは、XML または Groovy 構成メタデータのリソースの場所の配列（多くの場合、クラスパス内）またはアプリケーションの構成に使用されるコンポーネントクラスの配列を宣言します。これらのロケーションまたはクラスは、web.xml または実動デプロイのその他の構成ファイルで指定されているものと同じまたは類似しています。

デフォルトでは、ロードされると、構成された ApplicationContext は各テストで再利用されます。セットアップコストはテストスイートごとに 1 回だけ発生し、その後のテスト実行ははるかに高速です。このコンテキストでは、「テストスイート」という用語は、すべてのテストが同じ JVM で実行されることを意味します。たとえば、特定のプロジェクトまたはモジュールの Ant、Maven、Gradle ビルドから実行されるすべてのテストです。まれに、テストによってアプリケーションコンテキストが破損し、（たとえば、Bean 定義またはアプリケーションオブジェクトの状態を変更することによって）リロードが必要な場合、TestContext フレームワークは、次を実行する前に構成をリロードし、アプリケーションコンテキストを再構築するように構成できます。テスト。

TestContext フレームワークを使用したコンテキスト管理およびコンテキストキャッシングを参照してください。

テストフィクスチャの依存性注入

TestContext フレームワークがアプリケーションコンテキストをロードするとき、依存性注入を使用してテストクラスのインスタンスをオプションで構成できます。これは、アプリケーションコンテキストから事前に構成された Bean を使用して、テストフィクスチャをセットアップするための便利なメカニズムを提供します。ここでの大きな利点は、さまざまなテストシナリオ（たとえば、Spring 管理のオブジェクトグラフ、トランザクションプロキシ、DataSource インスタンスなどの構成）でアプリケーションコンテキストを再利用できるため、個々のテストで複雑なテストフィクスチャセットアップを複製する必要がないことです。ケース。

例として、Title ドメインエンティティのデータアクセスロジックを実装するクラス（HibernateTitleRepository）があるシナリオを考えます。次の領域をテストする統合テストを作成します。

  • Spring 構成: 基本的に、HibernateTitleRepository Bean の構成に関連するものはすべて正しく存在していますか？

  • Hibernate マッピングファイルの構成: すべてが正しくマッピングされており、適切な遅延読み込み設定が行われていますか？

  • HibernateTitleRepository のロジック: このクラスの構成済みインスタンスは予想どおりに機能しますか？

テストフィクスチャと TestContext フレームワークの依存性注入を参照してください。

トランザクション管理

実際のデータベースにアクセスするテストの一般的な課題の 1 つは、永続ストアの状態への影響です。開発データベースを使用する場合でも、状態の変更は将来のテストに影響を与える場合があります。また、永続データの挿入や変更などの多くの操作は、トランザクションの外部では実行（検証）できません。

TestContext フレームワークはこの課題に対処します。デフォルトでは、フレームワークは各テストのトランザクションを作成してロールバックします。トランザクションの存在を想定できるコードを作成できます。テストでトランザクション的にプロキシされたオブジェクトを呼び出す場合、設定されたトランザクションのセマンティクスに従って、それらは正しく動作します。さらに、テスト用に管理されているトランザクション内で実行中にテストメソッドが選択したテーブルの内容を削除すると、デフォルトでトランザクションがロールバックされ、データベースはテスト実行前の状態に戻ります。テストのアプリケーションコンテキストで定義された PlatformTransactionManager Bean を使用して、テストにトランザクションサポートが提供されます。

トランザクションをコミットする場合（通常ではありませんが、特定のテストでデータベースにデータを入力または変更する場合に役立つことがあります）、@Commit アノテーションを使用して、TestContext フレームワークにトランザクションをロールバックする代わりにコミットさせるように指示できます。

TestContext フレームワークを使用したトランザクション管理を参照してください。

統合テストのサポートクラス

Spring TestContext フレームワークは、統合テストの記述を簡素化するいくつかの abstract サポートクラスを提供します。これらの基本テストクラスは、テストフレームワークへの明確に定義されたフックと、便利なインスタンス変数およびメソッドを提供します。

  • ApplicationContext。明示的な Bean ルックアップを実行するか、コンテキスト全体の状態をテストします。

  • JdbcTemplate: SQL ステートメントを実行してデータベースにクエリを実行します。このようなクエリを使用すると、データベース関連のアプリケーションコードの実行前と実行後の両方でデータベースの状態を確認できます。Spring は、そのようなクエリがアプリケーションコードと同じトランザクションのスコープ内で実行されることを保証します。ORM ツールと組み合わせて使用する場合は、誤検知を必ず回避してください。

さらに、プロジェクト固有のインスタンス変数とメソッドを使用して、独自のカスタムアプリケーション全体のスーパークラスを作成することもできます。

TestContext フレームワークのサポートクラスを参照してください。