GemFire を使用する単体テスト サービスについては、テスト コンテキストに GemFire の「リージョン」を含めて、モックを回避し、Gemfire サーバーに依存することを計画しています。これを可能にするベストプラクティス/ツールは何ですか?
理論的には、以下が私たちが計画しているオプションです。
サービス --> GemFire (テストコンテキストに埋め込まれています)
コンテキストをブートストラップするには、ContextConfiguration: gfe-cache xml への参照を持つ test-applicationContext を追加します。
Junits はテスト コンテキストをロードし、リージョンをブートストラップします。これで、GemFire を使用して作成/フェッチ/削除を起動し、結果を検証できます。
あなたが説明しているのは統合テストであり、Spring Data GemFireが説明したのとほぼ同じですが、もう少し直接的です (つまり、GemFire 領域またはおそらく他の GemFire コンポーネントをテストクラスに直接注入します)。たとえば、GemFireTemplateIntegrationTestクラスとそれに関連付けられているSpring (XML) configを見てください。
これは、Spring Data GemFireが GemFire コンポーネントをテストで直接使用することに意味があります。ただし、これは実際のアプリケーション テスト スイートではおそらく理想的とは言えません。これは主に、適切な関心の分離と、アプリケーションが使用する依存関係の周りに適切なファサードを提供することを信じているためです。
言い換えれば、上でほのめかしたように、アプリケーションに次の（従来のn）層があります...
UI -> サービス -> DAO
サービス層は純粋なビジネス ロジックとルールであり、データ ストア (GemFire/Geode を含む) との対話 (CRUD、クエリ、関数の実行など) は DAO を介して行われます。
これにより、DAO のモックが非常に簡単になり、サービス テストのポイントに集中して、基になるデータ ストアの動作とは無関係にビジネス ロジックとルールをテストできます。
もちろん、適切なトランザクション動作を保証するため、または OQL (クエリ) ステートメントが適切に形成されていることを保証するためだけに、GemFire/Geode などの基礎となるデータ ストアとの適切な対話を保証するための統合テストを持つことが重要です。
ただし、DAO の実装に関しては多くのオプションがあります。
リージョンを DAO に挿入し、リージョンで直接操作 (CRUD、クエリなど) を実行できます。
Spring Data GemFireを使用している場合は、GemfireTemplate を使用して GemFire/Geode API を直接使用しないように DAO をシールドすることをお勧めします ( GemFire /Geode によって導入されたインターフェイスの重大な変更の場合、または GemFire/Geode 例外をラップする場合)。Spring の便利で一貫性のある (データ ストア間での)例外クラス階層(データ ストアを交換する場合に便利です)。詳しくはこちらをご覧ください。
最後に (重要なことではありませんが)、 GemFire/Geode をサポートするSpring Data Common のRepository 抽象化のSpring Data GemFire の 拡張を使用できます。これにより、DAO (別名リポジトリ) の実装が、 GemfireRepository を拡張するインターフェースを定義するのと同じくらい簡単になります。
どちらを選択するかは、希望する抽象化のレベルに依存し、それぞれの選択によって、統合テストへの取り組み方がわずかに変わります。
最後のヒントとして、これはまだ真の単体テストを作成することを妨げるものではありません。
Spring Data GemFireは、カスタム テスト フレームワーク(モックとスタブを使用) を採用して、GemFire コンポーネント (リージョン、AEQ、ゲートウェイなど) を含む単体テストを簡素化します。この「カスタム テスト フレームワーク」は、GemfireTestApplicationContextInitializerおよび関連するGemfireTestBeanPostProcessorに根ざしています。ロジックをたどると、それがどのように機能するかがわかります。
このカスタム テスト フレームワークは、 SDG の XML 名前空間を使用して作成および初期化された GemFire コンポーネントの有効性をテストするのに非常に役立ちます。ただし、GemFire/Geode コンポーネントの場合でも、構成メタデータをSpring構成に配置することがますます一般的になりつつあり、 Spring Data GemFire 1.9でさらに強化/簡素化することを検討しています。
さらに、この種の質問が寄せられているので、ある時点で、 Spring Data GemFire のカスタム テスト フレームワークをSpring Data GemFire の別のトップレベル Spring プロジェクト拡張機能に引き上げてリファクタリングするために、すでに開始している作業を行いたいと考えています。多くの。
とにかく、これがアプリケーションのテストにシンプルで簡潔で一貫した方法で最善のアプローチをするためのアイデアを提供してくれることを願っています。
乾杯！