デフォルトのコンテキスト構成
コンポーネントクラス、XML リソース、Groovy スクリプトのセクションに従って、テストの ApplicationContext をロードする @Configuration クラス、XML 構成ファイル、または Groovy スクリプトを明示的に指定しない場合、TestContext フレームワークはデフォルトのコンテキスト構成を検索しようとします。
ただし、検出アルゴリズムのバグにより、型階層または囲んでいるクラス階層 (@Nested テストクラスの場合) が @ContextConfiguration を宣言していない場合、スーパークラスまたは囲んでいるクラスのデフォルトのコンテキスト構成は現在無視されます。
Spring Framework 7.1 以降、TestContext フレームワークは、このようなシナリオにおいて、特定のテストクラスの上位の型階層または囲みクラス階層内のすべてのデフォルトコンテキスト構成を確実に検出します。その結果、7.1 へのアップグレード後にテストスイートで問題が発生する可能性があります。例: 前述のバグによりスーパークラスまたは囲みクラス内の静的ネストされた @Configuration クラスが無視される場合、7.1 でそのバグが修正されると、その @Configuration クラスは無視されなくなり、結果として生成される ApplicationContext に予期しない Bean が発生したり、テストが完全に失敗したりする可能性があります。
その間、TestContext フレームワークは、現在無視されているデフォルトのコンテキスト構成（たとえば、@Configuration クラスや XML 構成ファイルなど）を検出するたびに警告をログに記録します。このセクションの残りの部分では、テストスイートで警告が発生した場合の対処方法について説明します。
影響を受けるサブクラスまたは |
静的にネストされた @Configuration クラスを処理したくない場合は、次のことができます。
@Configuration宣言を削除してください。@ContextConfigurationは、実際にそのようなクラスを処理したい場合にのみ適用してください。静的にネストされた
@Configurationクラスを独立したトップレベルクラスに移動して、誤ってデフォルト設定クラスとして解釈されないようにしてください。
同様に、デフォルトの XML 設定ファイルや Groovy スクリプトが検出され、処理したくない場合は、以下の手順を実行できます。
@ContextConfigurationは、実際にそのようなリソースを処理したい場合にのみ適用してください。リソースファイルの名前を、デフォルトの命名規則（XML 設定の場合は
*-context.xmlなど）と一致しないものに変更してください。そうすることで、誤ってデフォルトの設定ファイルとして解釈されることを防ぐことができます。影響を受けるリソースファイルを、プロジェクト内の別のパッケージまたはファイルシステム上の場所に移動してください。
