多くは、SoapUIを使用して、API自体とAPIにアクセスするアプリケーションの両方をテストします。 たとえば、
swagger APIファイルをエクスポートし、それに基づいてMock-serviceを生成できる、かなり柔軟なツール。
少し前まで、私たちの会社では、同様の問題に直面しましたが、些細な状況ではありませんでした。 初期データ：入力としてタスクを受信するサーバーアプリケーションをテストする必要があります;実行中、APIを参照します;以降の各リクエストはAPIレスポンスに依存します。 ロジックはアプリケーションに組み込まれています。 つまり、スクリプトへの入り口が1つしかない場合に、スクリプトからの多数の出口をテストする必要がある一種のブラックボックスです。
以下に、シナリオの範囲とその複雑さの範囲を拡大する場合に、スケーリングマージンを確保するとともに、回帰インフラストラクチャに簡単に統合できるソリューションの例を提案します。
最初に、SoapUIでモックサービスを作成します。 これは、数回クリックするだけで実行できます。
次に、クエリのスタブの作成に移りましょう。 タスク内のスクリプトへのエントリは1つだけなので、オプションがあります。
- スクリプトの識別子を使用して、各リクエストでそれを渡し、各スタブでこの識別子に応じて応答を決定します。
- 各スタブの回答のリストを事前に指定し、テストを実行する前にグローバル変数に保存します。
最初のオプションは、複数の要求に対してスタブから同時に応答を受信する必要がある場合に使用できます。 実装では、クライアントアプリケーションが各APIリクエストで特定の識別子を送信できる必要があります。 私たちの場合、これは事実上不可能であり、いくつかのシナリオの同時テストは必要なかったため、2番目のオプションが選択されました。
したがって、スタブ応答のリストを割り当てるには、テストを実行する前に次のクエリを実行します。
Post: http:
Mockサービスでは、「SetScenario」を処理するリクエストを追加します。 応答は2つのみです。着信リクエストが正しく処理された場合は「200_OK」、リクエストが正しく行われなかった場合は「400_BadRequest」です。
スクリプトでは、各スタブの応答値をグローバル変数に分配します。
def reqBody = mockRequest.getRequestContent() // def reqBodyParams = [:] reqBody.tokenize("&").each // , { param-> def keyAndValue = param.split("=") reqBodyParams[keyAndValue[0]]=keyAndValue[1] } if (reqBodyParams.containsKey('ScenarioId')) // ID ( ); { // , , “?:” – : context.mockService.setPropertyValue("ScenarioId", reqBodyParams["ScenarioId"] ?: "0") context.mockService.setPropertyValue("Authentication", reqBodyParams["Authentication"] ?: "200_OK") context.mockService.setPropertyValue("AutoSystemHome", reqBodyParams["AutoSystemHome"] ?: "200_OK") // … return "200_OK" } else { return "400_BadRequest" }
割り当てられた変数は、サービス設定ウィンドウで確認できます。
したがって、このメソッドでMockサービスのロジック全体を説明し、APIメソッドのスタブでは、グローバル変数から応答値を読み取るスクリプトを作成するだけで十分です。
Authentication = context.mockService.getPropertyValue("Authentication") return "${Authentication}"
AutoSystemHome = context.mockService.getPropertyValue("AutoSystemHome") return "${AutoSystemHome}"
タイムアウトスクリプト、遅延応答を追加する必要がある場合は、次のように遅延変数を追加します。
Post: http://mockserver:8080/setscenario Body: ScenarioId=0&Delay=600&Authentication=200_OK &AutoSystemHome=400_TokenIsMissing…
そして、スタブスクリプトに以下を追加します。
… Authentication = context.mockService.getPropertyValue("Authentication") Delay = context.mockService.getPropertyValue("Delay").toInteger() sleep(Delay) return "${Authentication}"
繰り返されるリクエストをサポートする必要がある場合は、回答のリストを転送します。
Body: Authentication:400_MissingParametersClientId;400_MissingParametersClientId;200_OK
そして、処理スクリプトで、tokenizeを追加し、送信済みの応答が最後でない場合は削除します。
def Authentication = [] Authentication = context.mockService.getPropertyValue("Authentication").tokenize("%3B") if (Authentication.size() > 1) { Authentication.remove(0) Authentication = Authentication.join("%3B") context.mockService.setPropertyValue("Authentication", Authentication) }
その結果、プロジェクトファイルはxmlファイルであるため、テストベンチと環境の間を簡単に移動できる単純なMockサービスを取得しました。 サービスは、追加設定なしで、インポート後すぐに開始されます（もちろん、サーバーのアドレスとポートを変更する場合を除く）。 現時点では、IPAサーバーの安定性とアクセス不能の可能性のある期間に関係なく、アプリケーションのテストに役立ちます。
追加予定：APIの開発前および開発中にアプリケーションをテストするためにこのソリューションを統合します。 たとえば、説明がswaggerファイルの形式で既に準備されているが、サーバーがセットアップの処理中である場合。 API開発サイクルとクライアントアプリケーションは必ずしも一致しません。 この時点で、開発中のクライアントアプリケーションをテストしておくと便利です。Mockサービスは非常に役立ちます。
UPD：質問や役立つコメントがある場合。