0

各モジュールがリージョンとリポジトリのクラスを保持する複数のモジュールで構成されるプロジェクトがあります。

その問題は、各モジュールがgfe:cache独自のスプリング コンテキストに独自の Gemfire を持っていることです。

したがって、私の問題は、mvn testすべてのモジュールを実行すると、独自の Gemfire が起動し、テスト後に閉じるため、テストの実行に約 10 分かかり、Gemfire のすべてのインスタンスの起動に 40 秒かかることです。

それで、それを避けるための最良の方法は何ですか?

親モジュール(すべてのリポジトリとリージョンを保持)にリージョンを保持および作成させ、子モジュールのルックアップを使用してそれらを使用することを考えていました。ただし、モジュール テストの 1 つだけを実行する場合に備えて、個々のモジュールをそれらのモジュールで実行する必要もあります。

ルックアップを使用する方法はありますか? 失敗した場合は、同じリージョン ルックアップでキャッシュを作成しますか? または、キャッシュを一度作成して (最初のテスト)、他のコンテキストを閉じるのではなく開始している間にリージョンをキャッシュに追加しますか?

ありがとう

4

1 に答える 1

3

場合によっては、これを回避することはできません。特に、テスト スイートで後続のテストを実行するときに競合が発生するような方法で Spring コンテキストまたは GemFire インスタンスをダーティにした場合です。

つまり、おそらくテストクラスごとに GemFire インスタンスを再起動するだけではなく、作成する新しいテストクラスやテストケースごとに分離/分離を管理しようとする方が多くの作業が必要になる可能性があります。 (または、最悪の場合、テスト ケースごと)。たとえば、OQL クエリが、以前のテストのアクションまたはそのような性質のために予期しない結果を引き出すことを考えてみてください。

Spring Data GemFire テスト スイートは、テスト ケースごと、またはほとんどの場合、テスト クラスごとに、GemFire インスタンスを起動して停止するという点で非常に似ています。テスト (900 以上のテスト) を含むビルド全体は、平均で約 15 分で実行されます。GemFire 独自のテスト スイート (ユニット + 統合/分散テストなど) は、テストをどれだけ効果的に "並列化" できるかに応じて、約 8 ~ 12 時間で実行されます。oO

私は 10 分でビルドできると固く信じていますが、GemFire は複雑な獣であり、テスト、特に分散テストを作成するには、効果的に慎重な計画が必要です。

Spring Data GemFire のほとんどのテストはピア キャッシュ アプリケーションです (つまり、テスト JVM は GemFire インスタンスを埋め込みます。たとえば、RegionDataPolicyShortcutsIntegrationTestとそれに関連付けられたSpring コンテキスト構成ファイルです)。

いくつかの GemFire プロパティを設定すると (log-level を「warning」に設定し、特に mcast-port を 0 に設定するなど)、ランタイムを大幅に短縮できることがわかりまし。mcast-port を 0 に設定すると、「孤立した」GemFire ノードがセットアップされ、起動時間が大幅に短縮されます。

「ClientCaches」である他の Spring Data GemFire テストがあり、クライアント/サーバーの相互作用をテストするために、GemFire Server プロセスで別の JVM を生成することさえあります。開始/停止にさらに時間がかかるものを想像できますが、実際にはそうです。たとえば、ClientCacheFunctionExecutionWithPdxIntegrationTestと関連する Spring コンテキスト構成ファイル... ( server ) ともちろん ( client )。この場合、テストは GemFire ClientCache VM であることに注意してください。

これで、特定のテストでモックを使用する方法が得られるかもしれません。Spring Data GemFire テストの多くは、 org.springframework.data.gemfire.testパッケージで提供されるモックを使用して、SDG と GemFire の間の対話をモックします。

モックを使用する SDG のテスト クラスは、SDG GemfireTestApplicationContextInitializerを使用するGemfireTemplateTestのように、特別な種類の Spring ApplicationContextInitializer を宣言します。ただし、本当の魔法はGemfireTestBeanPostProcessorにあります。コードをたどると、アイデアが得られます。

いずれ、これらのモックを少し形式化して、これらのモック、GemfireTestApplicatonContextInitializer、および Spring と GemFire (および Apache Geode) を含む開発者テスト目的の関連する GemfireTestBeanPostProcessor を使用して別のプロジェクトを作成したいと考えています。

これにより、テストのセットアップと実行時の苦痛を軽減するためのいくつかのアイデアが得られることを願っています.

乾杯!

于 2015-06-15T17:25:50.920 に答える