Mule アプリケーションのテスト

ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​ソースコードの各ユニットの正しさを検証すること​です。

ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。

開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。

分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。
対象コードユニットを分離するには、MUnit が提供する ​mock-when​ プロセッサーなどのツールを使用します。

mock-when​ プロセッサーの使用例については、​「Foreach プロセッサーの前および内部のメッセージのモック」​を参照してください。

コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。

インテグレーションテストの目的は、​異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること​です。

アプリケーションの性質に応じて、インテグレーションテストに ​Sandbox​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。

機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。

たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。

インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。

コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。