コンテキストキャッシング
TestContext フレームワークがテスト用に ApplicationContext
(または WebApplicationContext
)をロードすると、そのコンテキストはキャッシュされ、同じテストスイート内で同じ一意のコンテキスト構成を宣言する後続のすべてのテストで再利用されます。キャッシングの仕組みを理解するには、「一意」と「テストスイート」の意味を理解することが重要です。
ApplicationContext
は、ロードに使用される構成パラメーターの組み合わせによって一意に識別できます。構成パラメーターの一意の組み合わせを使用して、コンテキストがキャッシュされるキーを生成します。TestContext フレームワークは、次の構成パラメーターを使用してコンテキストキャッシュキーを構築します。
locations
(@ContextConfiguration
から)classes
(@ContextConfiguration
から)contextInitializerClasses
(@ContextConfiguration
から)contextCustomizers
(ContextCustomizerFactory
から)–これには、@DynamicPropertySource
メソッド、@MockBean
や@SpyBean
などの Spring Boot のテストサポートからのさまざまな機能が含まれます。contextLoader
(@ContextConfiguration
から)parent
(@ContextHierarchy
から)activeProfiles
(@ActiveProfiles
から)propertySourceDescriptors
(@TestPropertySource
から)propertySourceProperties
(@TestPropertySource
から)resourceBasePath
(@WebAppConfiguration
から)
例: TestClassA
が @ContextConfiguration
の locations
(または value
)属性に {"app-config.xml", "test-config.xml"}
を指定する場合、TestContext フレームワークは対応する ApplicationContext
をロードし、それらのロケーションのみに基づくキーの static
コンテキストキャッシュに格納します。そのため、TestClassB
がその場所の {"app-config.xml", "test-config.xml"}
も(継承を介して明示的または暗黙的に)定義し、@WebAppConfiguration
、異なる ContextLoader
、異なるアクティブプロファイル、異なるコンテキスト初期化子、異なるテストプロパティソース、異なる親コンテキストを定義しない場合、同じ ApplicationContext
は両方のテストクラスで共有されます。これは、アプリケーションコンテキストを読み込むためのセットアップコストが 1 回(テストスイートごとに)発生するだけであり、その後のテスト実行がはるかに高速であることを意味します。
テストスイートと分岐プロセス Spring TestContext フレームワークは、アプリケーションコンテキストを静的キャッシュに格納します。これは、コンテキストが文字通り キャッシングメカニズムを活用するには、すべてのテストを同じプロセスまたはテストスイート内で実行する必要があります。これは、IDE 内のグループとしてすべてのテストを実行することで実現できます。同様に、Ant、Maven、Gradle などのビルドフレームワークでテストを実行する場合、ビルドフレームワークがテスト間で分岐しないことを確認することが重要です。例: Maven Surefire プラグインの |
コンテキストキャッシュのサイズは、デフォルトの最大サイズ 32 に制限されています。最大サイズに達すると、最も最近使用されていない(LRU)エビクションポリシーを使用して、古いコンテキストをエグジットして閉じます。spring.test.context.cache.maxSize
という名前の JVM システムプロパティを設定することにより、コマンドラインまたはビルドスクリプトから最大サイズを構成できます。別の方法として、SpringProperties
メカニズムを介して同じプロパティを設定できます。
特定のテストスイート内に多数のアプリケーションコンテキストをロードすると、スイートの実行に不必要に長い時間がかかる可能性があるため、ロードおよびキャッシュされたコンテキストの数を正確に把握することはしばしば有益です。基盤となるコンテキストキャッシュの統計を表示するには、org.springframework.test.context.cache
ロギングカテゴリのログレベルを DEBUG
に設定できます。
万が一、テストによってアプリケーションコンテキストが破損し、リロードが必要になった場合(たとえば、Bean 定義またはアプリケーションオブジェクトの状態を変更することにより)、テストクラスまたはテストメソッドに @DirtiesContext
アノテーションを付けることができます(の @DirtiesContext
の説明を参照)。Spring Test アノテーション)。これは、同じアプリケーションコンテキストを必要とする次のテストを実行する前に、キャッシュからコンテキストを削除してアプリケーションコンテキストを再構築するように Spring に指示します。@DirtiesContext
アノテーションのサポートは、デフォルトで有効になっている DirtiesContextBeforeModesTestExecutionListener
および DirtiesContextTestExecutionListener
によって提供されることに注意してください。
ApplicationContext のライフサイクルとコンソールログ Spring TestContext フレームワークで実行されたテストをデバッグする必要がある場合は、コンソール出力(つまり、 Spring Framework 自体または テストの テスト用の
特定のテストメソッドの後に Spring |