SoapUIモックサービス設定ガイドと最新代替案

TL;DR

SoapUIモックサービスはSOAPまたはRESTエンドポイントをローカルでシミュレートしますが、Javaプロセスの実行、手動ディスパッチ設定が必要であり、共有マシンなしではチーム間で共有できません。ApidogのSmart MockはAPIスキーマからモックレスポンスを生成し、クラウドで実行され、チームと自動的に共有されます。

💡

Apidogは、ローカルのJavaプロセスを実行することなく、API定義から瞬時にモックエンドポイントを作成するSmart Mockを内蔵した無料のオールインワンAPI開発プラットフォームです。Apidogを無料で試してみませんか？クレジットカードは不要です。

ボタン

はじめに

モックサービスは、API開発における共通の問題を解決します。つまり、サービスが準備される前にクライアントコードがサービスをどのように処理するかをテストしたい場合や、実際のシステムでエラーや応答遅延などのエッジケースを発生させることなくテストしたい場合です。

SoapUIのモックサービス機能は初期バージョンから利用可能で、機能します。これは、設定したルールに従ってリクエストに応答するローカルHTTPサーバーを実行します。問題は、このローカルプロセスが摩擦を生み出すことです。SoapUIを閉じると停止し、他のチームメンバーはネットワークトリックなしにはアクセスできず、設定インターフェースは扱いにくいものです。

このガイドでは、SoapUIのモックサービスの仕組み、設定方法、チームが直面する共通の問題、そしてApidogのアプローチがどのように異なるかについて説明します。

SoapUIモックサービスの仕組み

SoapUIは、プロジェクト内の既存のSOAPまたはRESTインターフェースからモックサービスを作成します。モックサービスは次のことを行います。

設定したローカルポート（例：http://localhost:8088/MockService）でリッスンします。
受信リクエストを傍受します。
ディスパッチロジックを使用して、リクエストを「モックレスポンス」に一致させます。
設定されたレスポンスを返します。

SOAPサービスの場合、SoapUIはWSDLからモックレスポンスを自動生成し、各操作のスタブレスポンスを作成できます。これは、サービスが存在する前や実際のéndpointにアクセスできる前にサービスをシミュレートするのに役立ちます。

SoapUIモックサービスの設定（ステップバイステップ）

SOAPインターフェースの場合

SoapUIプロジェクトで、プロジェクトツリー内のSOAPインターフェースを右クリックします。
「Generate MockService」を選択します。
ダイアログで以下を設定します。

サービス名（例：「OrderService Mock」）
ポート番号（デフォルトは8088。そのポートが使用中の場合は変更）
パス（例：/orders）

「OK」をクリックします。SoapUIはプロジェクトツリーにMockServiceノードを作成します。
MockServiceノードを展開します。インターフェース内の各SOAP操作に対して「MockOperation」が表示されます。
MockOperationをダブルクリックして、モックレスポンスエディタを開きます。
SOAPレスポンスXMLを編集して、シミュレートしたい値を返します。
MockServiceエディタの緑色の再生ボタンをクリックして、ローカルサーバーを開始します。

これで、モックはhttp://localhost:8088/ordersで実行されています。クライアントコードをこのURLに向けます。

RESTインターフェースの場合

プロジェクトツリー内のRESTインターフェースまたはリソースを右クリックします。
「Add to MockService」または「Generate MockService」を選択します。
上記のようにポートとパスを設定します。
各リソース/メソッドについて、モックレスポンスの本文とステータスコードを設定します。
モックサービスを開始します。

ディスパッチの設定

デフォルトでは、SoapUIのモックサービスは最初に見つかったモックレスポンスを返します。異なる入力に対して異なるレスポンスが必要な場合は、「ディスパッチスクリプト」（Groovy）を設定するか、「SEQUENCE」ディスパッチタイプを使用します。

Sequence dispatch（シーケンスディスパッチ）： 連続する呼び出しで固定順序でレスポンスを返します。呼び出し1はレスポンスAを取得し、呼び出し2はレスポンスBを取得します。

SCRIPT dispatch（スクリプトディスパッチ）： Groovyスクリプトがリクエストを検査し、ロジックに基づいてレスポンス名を返します。

ディスパッチスクリプトの例：

def request = mockRequest.getRequestContent()
if (request.contains("orderId>12345")) {
  return "OrderFoundResponse"
} else {
  return "OrderNotFoundResponse"
}

複数の名前付きモックレスポンス（例：「OrderFoundResponse」、「OrderNotFoundResponse」）を作成し、ディスパッチスクリプトが受信リクエストの内容に基づいてどちらを返すかを選択します。

SoapUIモックサービスのよくある問題

問題1：SoapUIを閉じるとモックが停止する

SoapUIのモックサービスは、SoapUIのJVMプロセスの一部として実行されます。SoapUIを閉じると、モックは停止します。モックを使用しているチームメイトはアクセスできなくなります。

回避策：

専用マシンまたはVMでSoapUIを開いたままにする
SoapUIのコマンドラインモックサーバーオプションを使用する：mockservicerunner.sh -p 8088 -s "OrderService Mock" project.xml
常にモックを実行する永続的な共有マシンを使用する

これらはいずれもエレガントではありません。コマンドラインオプションは役立ちますが、SoapUIとJavaがインストールされたマシンが依然として必要です。

問題2：チーム間でのモックの共有

localhost:8088上のモックは、それを実行している人にのみアクセス可能です。チームメイトが同じモックにアクセスするには、そのマシンへのネットワークアクセス（ファイアウォールルール、VPN設定）または共有サーバーでモックを実行する必要があります。

問題3：複雑なXMLでディスパッチスクリプトが機能しなくなる

SoapUIのディスパッチスクリプトは、生のXML本文に対してGroovyの文字列マッチングを使用します。SOAPエンベロープには名前空間があり、クライアントによっては同じ論理値が異なる名前空間プレフィックスで表示されることがあります。<orderId>12345</orderId>のようなリテラル文字列を検索するスクリプトは、プレフィックスが異なる場合に機能しなくなります。

この問題を解決するには、SoapUIのGroovyUtilsクラスを使用してディスパッチスクリプトで適切なXMLパースを行う必要があり、複雑さが増します。

問題4：呼び出し間で状態が永続しない

SoapUIのモックサービスはデフォルトでステートレスです。作成後に読み取るワークフロー（POSTで作成し、GETで取得する）をモックしたい場合、共有変数に状態を保存するGroovyディスパッチスクリプトが必要です。これは機能しますが、脆いものです。

問題5：モックサービス用のSSL

SoapUIモックサービス用のHTTPSを設定するには、キーストアのセットアップ、SoapUIのSSL設定、クライアントを適切な証明書に向ける作業が必要です。これはHTTPのみのモックよりもはるかに複雑です。

Apidog Smart Mock：比較

Apidogのモックアプローチは、実行中のプロセスからではなく、API設計から始まります。

ApidogでAPIエンドポイント（メソッド、パス、リクエストスキーマ、レスポンススキーマ）を定義すると、Apidogは自動的にクラウドにモックエンドポイントを生成します。設定は不要です。

モックURLは次のようになります： https://{your-project}.mock.apidog.io/orders/{id}

このURLは：

常に実行中（開始または停止するローカルプロセスがない）
プロジェクトへのアクセス権を持つすべてのチームメンバーがアクセス可能
定義したスキーマからレスポンスを生成

Apidogがモックレスポンスを生成する方法

Apidogはレスポンススキーマ（JSON SchemaまたはOpenAPIレスポンス定義）を読み取り、現実的な偽データを生成します。orderIdがUUID形式のstringであると示すスキーマは、ランダムなUUIDを返します。amountが0から10000までのnumberであると示すスキーマは、その範囲内の数値を返します。

特定のフィールドに対してカスタムモックルールを設定することもできます。予測可能な値が必要な場合は、orderIdを常に"test-123"を返すように設定します。

Apidog MockにおけるSOAPエンドポイント

ApidogのSmart Mockは、JSONレスポンスを持つRESTエンドポイント向けに設計されています。SOAPエンドポイントの場合、モック設定は手動です。Apidogでリクエストを作成し、SOAPエンベロープを含むカスタムレスポンスを設定し、Apidogのモックサーバーを使用してそれを返します。

これはSoapUIのWSDLベースのモック生成よりも自動化されていませんが、ローカルのJavaプロセスを実行することなく簡単なSOAPモックが必要なチームには機能します。

ステートフルモッキング

Apidogは、ステートフルなモック動作のためにカスタムレスポンススクリプトをサポートしています。JavaScriptモックスクリプトでリクエストボディを検査し、リクエストの内容に基づいて異なるレスポンスを返すことができます。これはSoapUIのディスパッチスクリプトに似ていますが、JavaScriptを使用します。

サイドバイサイド比較

機能	SoapUIモック	Apidog Smart Mock
Javaが必要	はい	いいえ
常時稼働	コマンドラインランナー使用時のみ	はい（クラウド）
チームアクセス可能	手動ネットワーク設定が必要	はい、共有URL経由
WSDL自動生成	はい	いいえ
RESTスキーマベース	いいえ	はい
動的レスポンス	Groovyディスパッチ	JavaScriptモックスクリプト
HTTPSサポート	手動キーストア設定	組み込み
ステートフルモッキング	Groovy変数経由	JavaScriptスクリプト経由
無料	はい	はい

それぞれの使用時期

SoapUIモックサービスを使用する場合：

WSDLベースのSOAPサービスをモックする必要があり、自動生成されたレスポンススタブが必要な場合
チームがオフラインで作業している、または厳格なネットワーク制御下にある場合
すでにSoapUIのエコシステムに深く入り込んでおり、ツールを変更したくない場合

Apidog Smart Mockを使用する場合：

チームがRESTエンドポイントをモックし、ネットワーク設定なしで共有アクセスが必要な場合
手動介入なしにモックサーバーを稼働させたい場合
新しいプロジェクトを開始し、実装前にAPI契約を定義している場合
モックサービスのためにJava環境のインストールとメンテナンスを避けたい場合

よくある質問

SoapUIモックサービスをヘッドレス（GUIなし）で実行できますか？はい。SoapUIにはmockservicerunner.sh（Linux/macOS）とmockservicerunner.bat（Windows）が含まれています。プロジェクトファイルのパスとサービス名を指定して実行します。Javaはインストールされている必要がありますが、GUIを開いておく必要はありません。

ApidogはSOAPモックサービスをサポートしていますか？部分的にサポートしています。ApidogのモックサーバーでSOAP XMLを含むカスタムレスポンスを設定できます。WSDLベースのスタブレスポンスの自動生成はありません。十分に理解されたSOAPインターフェースを持つチームにとっては、手動設定で対応可能です。

SoapUIモックサービスは応答遅延をシミュレートできますか？はい。モックレスポンス設定で「Delay」値をミリ秒単位で設定します。Apidogも、ネットワーク遅延のシミュレーションのために応答遅延設定をサポートしています。

Apidogはどれくらいのモックリクエストを処理できますか？Apidogのクラウドモックサーバーは、一般的な開発およびテストの負荷を処理します。大量のパフォーマンステストには、専用のモックサーバーツールの方が適している場合があります。

2人のチームメンバーが同じエンドポイントに対して異なるモックレスポンスを必要とする場合はどうなりますか？SoapUIでは、各人が自身のローカルモックを実行し、独立して設定できます。Apidogでは、複数の環境を作成したり、クエリパラメータを使用して異なるレスポンスシナリオを選択したりできます。Apidogの「Mock expects」機能を使用すると、特定のリクエスト条件を特定のレスポンスに一致させることができます。

Apidogのモックは、まずAPIを完全に定義する必要がありますか？レスポンススキーマはApidogが現実的なデータを生成するのに役立ちますが、完全なスキーマなしで手動でモックレスポンスを作成することもできます。エンドポイントを定義し、カスタムレスポンスボディを設定すれば、モックは機能します。

SoapUIのモックサービスは機能的ですが、ローカルのJavaプロセスに縛られています。永続的で共有可能なモックを必要とする現代のチームにとって、Apidogのクラウドベースのアプローチは調整のオーバーヘッドを排除します。

ボタン