2016-05-31 6 views
1

アプリケーションコンテキストを静的フィールドに設定するSpringコンポーネントがあります。この静的フィールドは、アプリケーションの他の部分からアクセスされます。私はstaticを使用すべきではないと知っていますが、バネ管理されていないBeanからSpringコンテキストにアクセスする必要があることがあります。例えば。フィールドには、次のようになります。Spring静的コンテキストアクセッサと統合テスト

public class ApplicationContextProvider implements ApplicationContextAware { 

    private static ApplicationContext context; 

    public ApplicationContext getApplicationContext() { 
     return context; 
    } 

    @Override 
    public void setApplicationContext(ApplicationContext ctx) { 
     context = ctx; 
    } 
} 

問題は、統合テストフレームワークをJUnitのを使用して(またはスポック)とき、新しい春のコンテキストがのような注釈を持つテストのために作成されていることである(http://www.dcalabresi.com/blog/java/spring-context-static-class/のために撮影したもの) @TestPropertySourceまたは@ContextConfigurationの場合、コンテキストは同じ設定(スプリングテストフレームワークのコンテキストキャッシング)で他のテスト用にキャッシュされます。

ただし、静的フィールドは、スプリングコンテキストが作成されたときにのみ更新されます。つまり、テストコンテキストがキャッシュから取得されると、コンテキストがキャッシュされる前に既に初期化されているため、静的フィールドは更新されません。静的フィールドは、前回のテスト実行で作成された最後のコンテキストによって異なる構成で上書きされていたため、テストを開始するコンテキストと同じコンテキストは表示されません。

結果は、テストの一部が1つのスプリングコンテキストで実行され、他のコンテキストで実行される静的フィールドにアクセスするポイントから実行されます。

誰にもこの問題の解決策がありますか?誰も同じ状況になった?

答えて

0

私は同じ問題に直面しました。 テストの前にコンテキストを保存してから復元する可能性があります。 便宜上つけ、それはJUnitのルールを介して行うことができる。

public class ContextRestoreRule extends ExternalResource { 

    private ApplicationContext context; 

    @Override 
    protected void before() throws Throwable { 
     context = ApplicationContextProvider.getContext(); 
    } 

    @Override 
    protected void after() { 
     ApplicationContextProvider.setContext(context); 
    } 
} 

および試験(WICHがコンテキストを変更)において:

@ClassRule 
public static ContextRestoreRule contextRestore = new ContextRestoreRule(); 
関連する問題