MuleSoft 入門(6)MUnit による単体テスト

December 19, 2019 Naoki Kitaarashi

こんにちは、アピリオ北嵐です。MuleSoft 入門シリーズ第3回4回で、Anypoint Studio での Mule API 開発の基本的な流れと DataWeave の基本についてご紹介しました。第6回目の今回は応用編ということで Anypoint Studio で開発したMule アプリケーションを JUnit ライクに単体テストできる MUnit をご紹介したいと思います。 

MUnit とは

MUnit は Mule フロー定義の検証用に Anypoint Studio の拡張 Plugin として提供されている単体テスト用のフレームワークです。 Java における JUnit と同じように、テストケースをプログラム(フロー定義)として準備して、テストスイートを実行することで単体テストを行うことができます。 各テストケースには期待値と実行結果を比較するアサーションを準備して、テストを実行すると JUnit と同じようにバーが表示され、視覚的にテストの成功/失敗が分かるようになっています。

[MUnit のテストケースと実行結果:テストの実行に失敗したケース]

2019 年 12 月時点のMUnitの最新バージョンは 2.2.2 になります。

MUnit の導入方法

(注意)最初にお伝えしておきますが、残念ながら MUnit の利用にはエンタープライズ・ライセンスが必要であり、無償で利用することはできません。ライセンスのないユーザーが MUnit を実行しようとすると、Plugin の導入はできますが、Maven による MUnit 関連ライブラリの取得に失敗します(Nexus リポジトリへのアクセス権がないため)。

Anypoint Studio への導入は簡単であり、下記の手順で行ってください。

1. Anypoint Studio に MUnit Plugin を導入する

メニューの [Help] – [Install New Software] から MUnit Update Site を選択し、最新バージョンを導入してください。

[Anypoint Studio Plugin 導入画面]

2. MUnit ライブラリの追加

プロジェクトに MUnit テストケースを追加するか、プロジェクトの右クリックメニュー [MUnit] - [Configure MUnit Maven Support] を選択すると、pom.xml に MUnit 関連ライブラリーの dependency が追加されます。

[pom.xmlの定義]

3. settings.xml への id/password のセット

MUnit テストケースの初回実行時に関連ライブラリが Nexus リポジトリから自動的にダウンロードされますが、この時に Maven の設定ファイル(ユーザーフォルダ/.m2/settings.xml)に Mule 組織の Nexusリポジトリの id/password の設定が必要になります。この id/password は Help Desk で Case を上げて Mule サポートに確認してください。

[settings.xml の id と password の設定]

MUnit テストの構成

MUnit におけるテストケースの作成方法ですが、キャンバスにテストケース単位で MUnit Test コンポーネントを配置して実装します。Test コンポーネントはテスト対象のフロー単位に作成し、下記のように3つのセクションから構成されています。

[MUnit Test コンポーネントの構成]

Execution セクションでは、Mule event(payload, attributes, variable)に指定されたデータをセットした後にテスト対象のフローを呼び出します。Behavior セクションでは、外部リソースへの呼出しを Mock 化できます。Validation セクションでは、実行後の検証(payload の中身、コネクタのコール回数の検証など)を行います。

MUnit は単体テストツールであるため、フローから外部リソースへの呼出し(API/SOAP、DBアクセスなど)を Mock 化できることは必要不可欠な機能です。この Mock 機能のサポートにより、ローカル環境でネットワーク上のリソースに接続することなく Mock を使ってフロー定義を検証することができるようになり、テストの自動化を実現できます。 

MUnit におけるテスト実行の流れ

MUnit によるテスト実行の流れは下記のようになります。

① テストを開始します

② Mule イベント(payload, attributes, variables)に値を設定することで、API のリクエストを再現します

③テスト対象のフローを呼び出します

④フローを実行し、API コールなどの外部リソース呼出は Mock 定義に応じてフックされ、指定した期待値がリソース呼出の結果として戻されます

⑤フローの実行結果を検証します

⑥テストを終了します

[MUnit におけるテスト実行の流れ]

テストコンポーネントは複数配置することができるため、テストの数だけ上記の検証が行われ、結果がビジュアルに報告されます。JUnit での実行と同じように全てのテストに成功すると実行バーは緑色になり、1つでもテストに失敗すると実行バーが赤く表示されます。昔からの習慣でしょうか、やはりバーが緑色に表示されると気持ちのよいものです。

[MUnitの実行:成功したケース]

パラメータ機能

MUnit バージョン 2.2から、パラメータを切り替えて1つのテストを繰り返し実行する機能がサポートされています。1つのフローに対して、入力パラメータの値をいくつかのバリエーションでテストしたい場合には便利な機能です。

パラメータの設定は、下記のように MUnit Configuration から行います。

1つのパラメータ設定ごとに任意の数のパラメータを指定することができます。下記の例では、  <munit:parameter> タグで "input" と "output" の2つのパラメータを定義し、json ファイルを読み込んでその内容をパラメータに設定しています。

[MUnit の実装コード:XML 表記]

input パラメータの値は execution セクションで Request payload の値(入力値)に設定し、output パラメータの値は validation セクションで検証の期待値として設定しています。下記のコード例では、<munit-tools:assert-that> タグで、期待値である output パラメータの値(vars.expectedValue)とフロー実行後の結果(payload)を比較して一致しない場合にエラーとなるように記述しています。

[MUnit の実装コード:XML 表記]

このパラメータ機能を使うことで、DataWeave スクリプトに対する単体テストを簡単に自動化することができます。DataWeave スクリプトは Mule 定義ファイル内にインライン記述するだけでなく、別ファイル(拡張子 dwl)として保管することができるため、テスト用に Transform だけを行うフロー定義を作成して dwl ファイルを読み込み、パラメータ機能を使って様々な入力値のバリエーションで DataWeave スクリプトを検証できます。 

[MUnit パラメータ機能による DataWeave スクリプトの自動検証]

カバレッジ機能

MUnit はフロー定義に対するカバレッジ機能も提供していて、実行後にフロー定義を見ると下記のように実行されたコンポーネントには緑色のチェックが表示されます。

[キャンバス上でのフロー定義に対するカバレッジの表示]

 

今回は Anypoint Studio で作成したフロー定義に対する単体テストを自動化できる MUnit をご紹介しました。フローの複雑度にもよりますが、ケースの数が増えると MUnit による検証用コードの作成はそれなりに大変です。しかしながら、一度テストケースを作成すれば、UT レベルのリグレッションテストを自動化できるため、変更時の機能検証を確実に行えるようになります。またフローに対する UT の実施確認も楽になります。この辺の効果は JUnit テストケースの作成と同じと考えていただいて良いと思います。

次回は MUnit による単体テストも含めて、Mule API 全体のテストの考え方についてご紹介したいと思います。 

 

[MuleSoft 入門シリーズ]

MuleSoft 入門(1)MuleSoft による API-led なアプリケーションネットワーク

MuleSoft 入門(2)ようこそ Anypoint Platform へ

MuleSoft 入門(3)Anypoint Studio による API の実装

MuleSoft 入門(4)DataWeave によるデータ変換

MuleSoft 入門(5)Flow Designer で Mule アプリケーションを開発

MuleSoft 入門(6)MUnit による単体テスト

MuleSoft 入門(7)API 開発におけるテストの考え方

MuleSoft 入門(8)ポリシーと SLA

MuleSoft 入門(9)カスタムポリシーの開発

MuleSoft 入門(10)Mule API のバージョン管理

MuleSoft 入門(11)ランタイムログの自動アーカイブ

著者について

Naoki Kitaarashi

アピリオのシニアコンサルとしてクラウドの世界に身を投じてはや5年あまり。プロジェクトでの立場に応じて、アーキテクト、リーダー、デベロッパーと様々なロールの仕事に携わっています。続々と新しいサービスと技術が登場するSalesforceの世界はエンジニアとして常に刺激を持ち続けられるエリアであり、2019年からはMuleSoftソリューションの起ち上げに関わっています。しばらくはAPI-ledなシステム連携を広めることに全力投球!!

Naoki Kitaarashi のコンテンツをもっと見る
戻る
MuleSoft入門(7)API開発におけるテストの考え方
MuleSoft入門(7)API開発におけるテストの考え方

今回は API 開発におけるテストについて考えていきます。単に動くだけのサンプルアプリを作るだけであれば、簡易的な検証で十分でしょうが、本番運用に耐えうる堅牢な API を開発するためには、一般的なシステム開発と同...

次へ
MuleSoft 入門(5)Flow Designer で Mule アプリケーションを開発
MuleSoft 入門(5)Flow Designer で Mule アプリケーションを開発

今回はクイックにAPIの開発を行いたいユーザー向けに、Design Centerが提供する Flow Designer を使ったブラウザ環境でのMuleアプリケーションの開発についてご紹介します。Flow Desi...

アピリオまでお気軽にお問合せください

ご質問はこちら