コンテキストキャッシング

TestContext フレームワークがテスト用に ApplicationContext （または WebApplicationContext）をロードすると、そのコンテキストはキャッシュされ、同じテストスイート内で同じ固有のコンテキスト設定を宣言する後続のすべてのテストで再利用されます。キャッシュの仕組みを理解するには、「固有」と「テストスイート」の意味を理解することが重要です。

ApplicationContext は、ロードに使用される構成パラメーターの組み合わせによって一意に識別できます。構成パラメーターの一意の組み合わせを使用して、コンテキストがキャッシュされるキーを生成します。TestContext フレームワークは、次の構成パラメーターを使用してコンテキストキャッシュキーを構築します。

たとえば、TestClassA が @ContextConfiguration の locations (または value) 属性に {"app-config.xml", "test-config.xml"} を指定している場合、TestContext フレームワークは対応する ApplicationContext をロードし、それらの場所にのみ基づくキーの下、static コンテキストキャッシュに格納します。そのため、TestClassB もその場所に {"app-config.xml", "test-config.xml"} を定義している (継承により明示的または暗黙的に) が、@WebAppConfiguration、異なる ContextLoader、異なるアクティブプロファイル、異なるコンテキスト初期化子、異なるコンテキストカスタマイザー、異なるテストまたは動的プロパティソース、または異なる親コンテキストを定義していない場合、同じ ApplicationContext が両方のテストクラスで共有されます。つまり、アプリケーションコンテキストをロードするためのセットアップコストは (テストスイートごとに) 1 回だけ発生し、後続のテスト実行ははるかに高速になります。

コンテキストキャッシュのサイズは、デフォルトの最大サイズ 32 に制限されています。最大サイズに達すると、最も最近使用されていない（LRU）エビクションポリシーを使用して、古いコンテキストをエグジットして閉じます。spring.test.context.cache.maxSize という名前の JVM システムプロパティを設定することにより、コマンドラインまたはビルドスクリプトから最大サイズを構成できます。別の方法として、SpringProperties メカニズムを介して同じプロパティを設定できます。

特定のテストスイート内に多数のアプリケーションコンテキストをロードすると、スイートの実行に不必要に長い時間がかかる可能性があるため、ロードおよびキャッシュされたコンテキストの数を正確に把握することはしばしば有益です。基盤となるコンテキストキャッシュの統計を表示するには、org.springframework.test.context.cache ロギングカテゴリのログレベルを DEBUG に設定できます。

万が一、テストによってアプリケーションコンテキストが破損し、リロードが必要になった場合（たとえば、Bean 定義またはアプリケーションオブジェクトの状態を変更することにより）、テストクラスまたはテストメソッドに @DirtiesContext アノテーションを付けることができます（の @DirtiesContext の説明を参照）。Spring Test アノテーション）。これは、同じアプリケーションコンテキストを必要とする次のテストを実行する前に、キャッシュからコンテキストを削除してアプリケーションコンテキストを再構築するように Spring に指示します。@DirtiesContext アノテーションのサポートは、デフォルトで有効になっている DirtiesContextBeforeModesTestExecutionListener および DirtiesContextTestExecutionListener によって提供されることに注意してください。