13

私は現在、「jUnitやMockitoなどのフレームワークを使用してOSGiコンポーネントのテストを簡単に作成できるようにOSGiコンポーネントを設計する方法」を考えています。

OSGiはDIP （依存性逆転の原則）を強化し、インジェクター方式（セッターなど）が通常存在するため、バンドル間の依存関係をあざけるのは非常に簡単です。
しかし、バンドルの内部依存関係はどうですか？

たとえば、この場合を見てください。今度はそれをOSGiコンテキストに持ち込みたい...OSGiプラットフォームで宣言型サービスとしてあらゆる種類のネットワークプロトコルを提供し、直接相互作用している下位のネットワークコードをテストするための単体テストを記述したいイメージソケットオブジェクト。

ソケットの作成を別の、しかしバンドルされた内部POJO （Plain Old Java Object）クラスにリファクタリングする場合、プロトコル実装にどのように注入する必要がありますか？

  • 単体テストでは、単純にセッターメソッドを使用できますが、OSGiコンテナーでこれを行うのは誰ですか？
  • テストされたクラスをサブクラス化し、creator-methodを上書きすることは、テストされたクラスがfinalとして宣言されていない場合にのみ機能します。
4

1 に答える 1

8

OSGiコンテナーとの相互作用のテストは、厳密に言えば、統合テストです。このために、 Pax Examを使用できます。コツをつかむのは少し面倒ですが、非常にうまく機能します（特に、MavenやKarafの機能を使用している場合）。

さらに、テスト内から展開可能なバンドル/フラグメントを動的に作成できるTinyBundlesを使用して（非常にクール）、他のバンドル/フラグメントをモックアウトして、完全な環境を起動せずにバンドル間の統合を保証できます。

ユニットまたは小規模の統合テスト（つまり、コンテナーなし）の場合、必要に応じてBundleContextをモックアウトできます（DSを使用している場合はComponentContextもモックアウトできます）。

箇条書きの質問については少しわかりません。内部POJOがある場合は、セッターを介して依存関係を接続する必要があります。そうでない場合、OSGiサービスレジストリに公開されている場合、依存関係はフレームワーク（DSまたはServiceTracker）によって解決されます。

また、creator-methodを上書きするために何かをサブクラス化すると、元のクラスをテストしなくなります-これはコードの臭いです-別のクラス（コンストラクターまたはセッター）としてクリエーターコードを渡すようにリファクタリングしてから、この新しいクリエーターコードを試してください（ソケットの作成）は独立してテストできます（OSGiやそれが使用されるプロトコルクラスを考慮せずに）。

于 2011-08-10T10:59:33.307 に答える