--- schema_version: "1" id: b887349d88a462b8006db3bedb707bc72e3b3679a399f74731747bb917d9215d title: Mule アプリケーションのテスト collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-runtime/4.3/test-mule-applications.md canonical_url: https://docs.mulesoft.com/jp/mule-runtime/4.3/test-mule-applications source_site: docs.mulesoft.com content_type: documentation content_hash: 3d70d4936e96d0f4edf191203297e677de9f4c8364b857feecb43b68f4ad0826 description: MuleSoft Documentation Site release: "4.3" latest: false --- # Mule アプリケーションのテスト Mule アプリケーション用に自動化されたテストの包括的なスイートを構築すれば、ローカル環境でのテスト中にアプリケーション内の回帰や互換性のない変更を検出できます。MUnit は Mule テストフレームワークであり、​_ユニット_​テスト、​_インテグレーション_​テスト、​_機能_​テストを使用して、Mule アプリケーションのテストを容易に自動化できます。MUnit には、分離環境でコードのユニットをテストできるプロセッサーモックフレームワークなど、一連のツールも用意されています。 詳細は、​[MUnit](https://docs.mulesoft.com/munit/latest/)​ のドキュメントを参照してください。 アプリケーションを作成するときは、コードのモジュール化などのベストプラクティスに従い、コードのテストが容易になるように短いフローを記述します。問題を識別して解決しやすくなるように、わかりやすい名前とエラーメッセージを使用して読みやすく維持しやすいテストを作成します。 Anypoint Studio のテストレコーダー (ベータ) を使用すると、処理フローを記録してから、取得されたイベントに基づいてユニットテストを設定できます。 詳細と例は、​[「Studio のテストレコーダー」](https://docs.mulesoft.com/munit/latest/test-recorder)​を参照してください。 アプリケーションのロジックおよび動作をテストしたら、Mule Runtime Engine (Mule) をプロファイリングして Mule アプリケーションのパフォーマンスをテストできます。このプロセスにより、Mule アプリケーションやカスタム Mule 拡張機能でのメモリやパフォーマンスに関連した問題を識別しやすくなります。Mule をプロファイリングするには、Java プロファイラーをオンプレミス Mule インスタンスに読み込む必要があります。 詳細な手順は、​[「Mule のプロファイリング」](https://docs.mulesoft.com/jp/mule-runtime/4.3/profiling-mule)​を参照してください。 ## [](#ユニットテスト)ユニットテスト ユニットテストの概念はプログラミングのパラダイムに応じて異なりますが、その中核的な概念は常に​_ソースコードの各ユニットの正しさを検証すること_​です。 ユニットテストのコンテキストでは、コードのユニットとはアプリケーションのテスト可能な最小の部分を指します。アプリケーションのテスト可能な最小の部分の実際の構成要素は、アプリケーションに応じて異なります。Mule アプリケーションの場合、テスト可能な最小の部分とは Mule フローまたはサブフローです。 開発者として、テストするコードが他のコードのユニットまたはコンポーネントとやりとりするかどうかを評価し、必ずテスト対象のコードのユニットを分離するようにユニットテストをデザインする必要があります。 分離により、テストに失敗した場合は、その原因が他のコードやコンポーネントではなくテスト対象のコードに関連するようにできます。 対象コードユニットを分離するには、MUnit が提供する ​`mock-when`​ プロセッサーなどのツールを使用します。 `mock-when`​ プロセッサーの使用例については、​[「Foreach プロセッサーの前および内部のメッセージのモック」](https://docs.mulesoft.com/munit/latest/mock-before-after-foreach-cookbook)​を参照してください。 ## [](#インテグレーションテスト)インテグレーションテスト コードのユニットが組み合わさって実際のアプリケーションを構成するため、これらのユニットを正常にテストしたら、インテグレーションテストを使用してアプリケーション全体をテストする準備が整います。 インテグレーションテストの目的は、​_異なるコードのユニットおよびモジュールが意図したとおりに連携して機能することを検証すること_​です。 アプリケーションの性質に応じて、インテグレーションテストに ​_Sandbox_​ テスト環境が必要になる場合もあります。これにより、本番のアプリケーション環境の外部で分離されたテスト評価を行うことができます。意図した結果を得るには、Sandbox のデータの状態がテストに適切であることを確認する必要があります。この検証は、インテグレーションテストを実行する前後に実行します。 ## [](#機能テスト)機能テスト 機能テストでは、Mule アプリケーション全体に想定されるユースケースをテストします。 たとえば、2 つのシステム間の双方向同期を維持するための Mule アプリケーションをテストするために、各システムでエントリを作成し、もう一方での複製を検証するテストケースをデザインできます。または、バッチ処理アプリケーションをテストする場合は、典型的な一連の情報を使用してテストを実行し、バッチの結果を検証できます。最後に、サービスオーケストレーションをテストするには、フローの一端でイベントを生成し、イベントがさまざまなサービスを通過した後に、もう一端で結果をテストすることができます。 インテグレーションテストの場合と同様、機能テストケースはテスト専用の環境プロパティおよびサービスのバージョンを使用して実行します。 ## [](#テスト可能なコードの記述)テスト可能なコードの記述 コードをモジュール化して実行環境を定義すれば、テストがきわめて容易になります (さらに、より設定項目が多く、拡張可能で読みやすいアプリケーションを作成できます)。 - コードをモジュール化する コードを異なるファイルに分割すれば、読みやすさが向上します。そのためには、共通の目標を達成するために連携するフローをグループ化するか、特定の機能的条件に従ってコードをグループ化します。 - 短いフローを記述する 長いフローは理解やコーディング、維持が難しくなる場合があるため、避けるのが得策です。ユニットテストの観点から見ると、長いフローでは 1 つのポイントからトリガーできるシナリオが多すぎるため、1 つのシナリオを検証するために非常に複雑な評価を実行する必要があるということになります。 - 実行環境を定義する プレースホルダーを使用してコードをパラメーター化します。この通常のユースケースには、DB や HTTP などのアウトバウンドエンドポイントのアドレスが含まれます。プレースホルダーを使用することで、テスト (ユニットまたはインテグレーション) 実行時に実際のアドレスを変更でき、環境 (DEV/QA/UAT/PROD) 間でコードを昇格させるのが容易になります。 ## [](#テスト作成のベストプラクティス)テスト作成のベストプラクティス - 読みやすく維持しやすくなるようにテストを作成します。 - テストが失敗したときに確認する内容に従ってテストに名前を付けます。 - テストが失敗したときに誤って記述されたエラーメッセージや曖昧なエラーメッセージが表示されないように、失敗時にテストによってスローされるわかりやすい名前を使用します。 - 長いフローは理解しにくくなるため、使用を避けます。 - カバーされるシナリオと失敗の条件が明示的になるようにテストをコーディングします。 ## [](#関連情報)関連情報 - [MUnit テスト構造の基礎](https://docs.mulesoft.com/munit/latest/munit-test-concept) - [MUnit の例](https://docs.mulesoft.com/munit/latest/munit-cookbook)