-1

TestAに依存するConfigAとにTestB依存する 基本的なテスト セットアップがありますConfigB。 

@Configuration
public class ConfigA {

    // define A beans

}

@Configuration
public class ConfigB {

    // define B beans

}

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { ConfigA.class })
public class TestA {

    @Test
    public void testA() {
        // test with A beans
    }

}

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes = { ConfigB.class })
public class TestB {

    @Test
    public void testB() {
        // test with B beans
    }

}

テストスイートTestAを使用して両方を実行したい。TestBAllTests

@RunWith(Suite.class)
@SuiteClasses({ TestA.class, TestB.class })
public class AllTests {

}

現状では、実行AllTestsすると、Spring は実行時に両方ともロードConfigAさConfigBれます。

統合して統合ConfigAし、代わりに両方のテストを使用する方がパフォーマンスが向上しますか?ConfigBConfigCConfigC

@Configuration
public class ConfigC {

    // define A and B beans

}
4

1 に答える 1

1

パフォーマンスに関しては、多かれ少なかれ同じである必要があります-Spring テストはいずれかの方法でコンテキストをキャッシュするため、他のテストのいずれかが ContextA または ContextB のいずれかを使用する場合、テストごとに再作成されるのではなく、キャッシュから再利用されます。2 つの別個のコンテキスト (A と B) を使用すると、統合されたコンテキストよりもオーバーヘッドが少し大きくなりますが、それほど気にならないはずです。

公式ドキュメントからの引用は次のとおりです。

Spring TestContext フレームワークは、Spring ApplicationContexts と WebApplicationContexts の一貫した読み込みと、それらのコンテキストのキャッシュを提供します。起動時間が問題になる可能性があるため、読み込まれたコンテキストのキャッシュのサポートは重要です。これは、Spring 自体のオーバーヘッドが原因ではなく、Spring コンテナーによってインスタンス化されたオブジェクトのインスタンス化に時間がかかるためです。たとえば、50 ～ 100 個の Hibernate マッピング ファイルを含むプロジェクトでは、マッピング ファイルのロードに 10 ～ 20 秒かかる場合があり、すべてのテスト フィクスチャですべてのテストを実行する前にそのコストが発生すると、全体的なテスト実行が遅くなり、開発者の生産性が低下します。

デフォルトでは、ロードされると、設定された ApplicationContext が各テストで再利用されます。したがって、セットアップ コストはテスト スイートごとに 1 回だけ発生し、その後のテスト実行ははるかに高速になります。このコンテキストでは、テスト スイートという用語は、同じ JVM で実行されるすべてのテストを意味します。たとえば、特定のプロジェクトまたはモジュールの Ant、Maven、または Gradle ビルドから実行されるすべてのテストです。

コンテキスト キャッシングに関する公式ドキュメントからの注目すべき引用を次に示します。

Spring TestContext フレームワークは、アプリケーション コンテキストを静的キャッシュに格納します。これは、コンテキストが文字通り静的変数に格納されることを意味します。つまり、テストが別々のプロセスで実行される場合、静的キャッシュは各テスト実行の間にクリアされ、これによりキャッシュメカニズムが効果的に無効になります。

キャッシュ メカニズムを利用するには、すべてのテストを同じプロセスまたはテスト スイート内で実行する必要があります。これは、IDE 内ですべてのテストをグループとして実行することで実現できます。同様に、Ant、Maven、Gradle などのビルド フレームワークを使用してテストを実行する場合、ビルド フレームワークがテスト間で分岐しないようにすることが重要です。たとえば、Maven Surefire プラグインのforkMode がalwaysまたはpertestに設定されている場合、TestContext フレームワークはテスト クラス間でアプリケーション コンテキストをキャッシュできず、結果としてビルド プロセスの実行が大幅に遅くなります。

Spring Framework 4.3 以降、コンテキスト キャッシュのサイズは、デフォルトの最大サイズである 32 に制限されています。最大サイズに達すると、LRU (最長時間未使用) エビクション ポリシーを使用して、古いコンテキストをエビクトして閉じます。という名前の JVM システム プロパティを設定することにより、コマンド ラインまたはビルド スクリプトから最大サイズを構成できますspring.test.context.cache.maxSize。別の方法として、同じプロパティを SpringProperties API を介してプログラムで設定できます。

于 2016-08-10T08:42:19.217 に答える