コンテキストカスタマイザーを使用した構成の構成
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
は、前述の自動検出メカニズムを使用して登録されたデフォルトファクトリとマージされます。
マージアルゴリズムにより、マージ時に重複がリストから削除され、ローカルに宣言されたファクトリがデフォルトファクトリのリストに追加されることが保証されます。
テストクラス、そのサブクラス、そのネストされたクラスのデフォルトファクトリを置き換えるには、 |