みなさん、こんにちは。
これまでMuleのフロー作成方法やSalesforceとの連携方法などの実装方法を解説してきましたが、
今回は開発工程で必要となるMUnitを使用したMuleフローの単体テスト実施について、実際に動作を確認しながら実施していきたいと思います。
目的・ゴール
- MUnitを使用してMuleフローの単体テストをする
- 連携を伴う機能部分はモックを使用して擬似環境を作成する
- 正常ケース/異常ケースをそれぞれ作成し、カバレージを100%にする
今回テストするフロー
今回は以下のフローをテスト対象として実際にMUnitを作成していきます。
![テスト対象のフロー](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.22.11-1024x794.png)
Salesforceへの連携を伴いますが、単体テストのため今回は実際にSalesforceには接続せずにモックを使用して擬似結果を返却するようにします。
テストクラスの構成
テストクラスはExecution、Behavior、Validationのスコープから構成されます。
![テストクラスの構成](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-16.41.36.png)
スコープ | 用途 |
---|---|
Execution | 実際に実行されるテストのフローになります。 ここからテストフローが開始され、テスト対象となるフローを呼び出します。 事前に投入しておくテストデータやパラメータなどがあれば呼び出し前にこのスコープで設定しておきます。 |
Behavior | 主にモックを設定する箇所となります。 サブフローの呼び出しやシステム連携が伴うコンポーネントについては、ここで疑似結果を設定します。 モックの設定の仕方は後述します。 |
Validation | テストフロー実行後の結果の検証を実施する箇所になります。 Payloadの値や変数の値など期待値と付き合わせて一致すればテストがOKとなります。 |
テストケースの作成
では実際にMUnitからテストケースを作成してみましょう。
MUnitのテストはプロジェクトからsrc/test/munitを選択してNew→MUnit Testを選択します。
![テストクラスの作成](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-16.35.11-915x1024.png)
作成時にテスト対象のフローが選択できるので、テストしたいフローを選択したOKを選択します。今回はgetAccountsのフローをテストするため、getAccountsまで選択します。
![テストクラスの作成](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-16.40.57-1024x873.png)
選択後、フロー呼び出しまで自動で作成したテンプレートが反映されます。
![テストケースのテンプレート](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-16.41.36.png)
正常パターンのテストケース
まずは正常パターンのテストケースを作成します。作成済みのテストフローからExecution、Behavior、Validationをそれぞれ肉付けしていきます。
モックの作成
Salesforceのクエリーの部分をモックを使用して、あたかもSalesforceに接続したように疑似結果を返却するようにします。
モックはMUnit ToolsのモジュールからMock Thenをドラッグアンドドロップします。
![モックの配置](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-17.05.57-1024x633.png)
Mock Thenコンポーネントの設定からPick processerを選択し、疑似結果を設定したいコンポーネンを選択します。
![モックの設定](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-17.14.05-1024x364.png)
今回はSalesforceのクエリーに対してモックを設定したいので、Queryを選択します。そして必ずdoc:idにチェックを入れて下さい。このdoc:id(コンポーネントの一意名)が一致することにより、実際の処理をモックに置き換える仕組みになっています。
![モックにdoc:idを設定する](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-17.14.51-1024x727.png)
doc:idを含めたモックを設定した後は、疑似結果を設定します。Then returnにPayloadタブがあるので、ここでQuery実施した検索結果を設定します。
モックのValueには、クエリーで検索した結果が返ってくるだろう値を設定します。QueryはJavaフォーマットで返却されるため、Media Typeをapplication/javaにして、ValueにはAccountが1件だけ返却されるような結果を設定します。
![モックの設定](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-19.07.35-1024x540.png)
%dw 2.0
output application/java
---
[
{
"Id": "0015h00000VzxLVAAZ",
"type": "Account",
"Name": "テスト"
}
]
テストケースの作成
Behavior部分は設定しましたので、残りのExecution、Validation部分を設定していきます。
まずはExecution部分ですが、すでにテスト対象となるgetAccountsフローを呼び出すロジックが組み込まれているのでこのままの状態でOKです。今回は簡潔なテストケースですが、URLパラメータや変数などで設定値がある場合は、Flow Reference前にSet Payloadなどの設定をつけてきますが、今回は特に入力するものはないため、デフォルトで作成されたFlow Referenceのみ配置すればOKです。
Validationには結果を検証するためのチェックを入れます。今回はクエリーで実行して結果をPayloadとして返すロジックとなっているため、Payloadが期待値通りになっているかの検証をします。Validation領域にMUnit ToolsのAssert equalsを追加し、Actialにはpayloadを、Expectedには期待値を設定します。
![Asser qeualsの期待値設定](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-19.26.09-1024x344.png)
Expectdに設定する期待値(output application/jsonは不要です)は以下モックをJSON形式にした値を設定します。
[
{
"Id": "0015h00000VzxLVAAZ",
"type": "Account",
"Name": "テスト"
}
]
これで一通りテストケースの作成は終了です。テストフロー名やコンポーネント名など調整してテストフローは以下のようになりました。
![正常パターンのテストケース](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-19.38.09.png)
テスト実行
MUnitをテスト実行する場合は、テストフローを右クリックしてRun MUnit Testから実行します。デバッグする場合はDebug MUnit TestからでもOKです。
![テスト実行](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-19.39.58-1024x443.png)
テストを実行するとMUnitにテスト結果が表示されます。緑色のバーが出ればテストOKです。
![テスト実行結果](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-19.41.52-1024x315.png)
テストを実施すると、テスト対象となったフローに緑色のチェックマークが表示されます。このチェックマークがついたところが実際に通過したフローになります。
![テスト実施後のフロー通過状況](https://quanz.co.jp/blog/wp-content/uploads/2024/01/スクリーンショット-2024-01-20-19.43.36-1024x731.png)
異常パターンのテストケース
次に異常パターンのテストケースを作成してみます。Queryのところで例外を発生させて、エラー処理へ流すルートをテストします。
テストケースの作成
上記で作成したテストケースとは別にエラー用のテストケースを作成します。MUnitのTestをドラッグアンドドロップしてテストケースを追加します。Executionは正常ケースと同じなので、同様にFlow Referenceを配置しましょう。
![テストケースの追加](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.08.09-1024x778.png)
Validation領域には、正常ケース同様にAssert equalsを配置します。例外をキャッチした後にSet Payloadにてメッセージが設定されるので、メッセージ付きのJSONを期待値に設定します。
![Asser qeualsの期待値設定](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.52.09-1024x832.png)
モックの作成
続いてモックを作成します。Mock Thenの配置とdoc:idの設定は正常の時と一緒です。今回は正常結果ではなくて例外を発生させる結果を返却したいので、ErrorタブのTypeに「SALESFORCE:TIMEOUT」を記載します。これで、例外SALESFORCE:TIMEOUTをスローするモックが出来上がります。
![例外をスローするモック](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.17.45-1024x429.png)
異常ケースのテストケースは以下のようなフローになります。
![異常パターンのテストケース](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-17.17.21.png)
テスト実行
それでは異常ケースでもテストをしてみましょう。
![テスト実行結果](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.50.57-1024x328.png)
こちらもテストが成功しました。テスト対象となったフローも確認してみましょう。
![テスト実施後のフロー通過状況](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.39.12-1024x727.png)
このように、Queryから先にはチェックマークがついていないことから、Queryで例外が発生して例外処理されたことが分かります。
全体をテストする
では、最終目的であるカバレージ100%になっているかを確認してみます。個別ではなく全体のテストケースをまとめて実行するにはテストケースのフローの外側で右クリック→Run MUnit siteで実行します(他にもテスト実行する方法はあります)。
![テスト実行](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-16.59.40-1024x640.png)
テスト結果を見てみましょう。2つのテストケースがまとめて実行され、どちらとも成功していることが分かりました。
![テスト実行結果](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-17.00.55-1024x378.png)
テスト対象となったフローも見てみると、全てのコンポーネントにチェックがついていることが分かります。
![テスト実施後のフロー通過状況](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-17.02.17-1024x715.png)
カバレージも見てみましょう。MUnit Coverageも100%と出ているので成功です!
![テスト実行後のカバレージ](https://quanz.co.jp/blog/wp-content/uploads/2024/02/スクリーンショット-2024-02-03-17.20.32.png)
最後に
簡単ではありますが、MUnitを使用してMuleフローのテストケースの作成と実行の仕方を一通り実施してみました。実際はもっと複雑なフローで実施することが多いため、テストパターンも複数個用意したり、エラーパターンも様々なケースを想定しておかなければならないため、より工数のかかる作業となります。開発の際はMUnitのテストケース作成も考慮に入れた見積もりをするようにしましょう。