コンテキストカスタマイザーを使用した構成の構成

ContextCustomizer は、Bean 定義がコンテキストにロードされた後、コンテキストがリフレッシュされる前に、提供された ConfigurableApplicationContext をカスタマイズする責任があります。

ContextCustomizerFactory は、指定されたテストクラスに ContextCustomizer が必要かどうかを判断するカスタムロジック (たとえば、特定のアノテーションの存在に基づいて) に基づいて、ContextCustomizer を作成します。ファクトリは、ContextLoaders がテストクラスのコンテキスト構成属性を処理した後、MergedContextConfiguration が作成される前に呼び出されます。

例: Spring Framework は、デフォルトで登録されている次の ContextCustomizerFactory 実装を提供します。

MockServerContainerContextCustomizerFactory

クラスパスに WebSocket サポートが存在し、テストクラスまたはその囲みクラスの 1 つが @WebAppConfiguration でアノテーションまたはメタアノテーションが付けられている場合は、MockServerContainerContextCustomizer を作成します。MockServerContainerContextCustomizer は新しい MockServerContainer をインスタンス化し、それを jakarta.websocket.server.ServerContainer という名前の属性の ServletContext に保存します。

ContextCustomizerFactory 実装の登録

@ContextCustomizerFactories アノテーションを使用して、テストクラス、そのサブクラス、そのネストされたクラスの ContextCustomizerFactory 実装を明示的に登録できます。詳細と例については、アノテーションのサポート@ContextCustomizerFactories (Javadoc) の javadoc を参照してください。

デフォルトの ContextCustomizerFactory 実装の自動検出

@ContextCustomizerFactories を使用した ContextCustomizerFactory 実装の登録は、限られたテストシナリオで使用されるカスタムファクトリに適しています。ただし、カスタムファクトリをテストスイート全体で使用する必要がある場合は、面倒になる可能性があります。この課題は、SpringFactoriesLoader メカニズムによるデフォルトの ContextCustomizerFactory 実装の自動検出のサポートによって解決されます。

例: Spring Framework および Spring Boot のテストサポートを構成するモジュールは、META-INF/spring.factories プロパティファイルの org.springframework.test.context.ContextCustomizerFactory キーですべてのコアのデフォルト ContextCustomizerFactory 実装を宣言します。spring-test モジュールの spring.factories ファイルは、ここで参照できます。サードパーティのフレームワークと開発者は、独自の spring.factories ファイルを通じて、同様のメソッドで独自の ContextCustomizerFactory 実装をデフォルトファクトリのリストに提供できます。

ContextCustomizerFactory 実装のマージ

カスタム ContextCustomizerFactory が @ContextCustomizerFactories 経由で登録される場合、そのカスタム ContextCustomizerFactory は、前述の自動検出メカニズムを使用して登録されたデフォルトファクトリとマージされます。

マージアルゴリズムにより、マージ時に重複がリストから削除され、ローカルに宣言されたファクトリがデフォルトファクトリのリストに追加されることが保証されます。

テストクラス、そのサブクラス、そのネストされたクラスのデフォルトファクトリを置き換えるには、@ContextCustomizerFactories の mergeMode 属性を MergeMode.REPLACE_DEFAULTS に設定します。