wiremock tutorial introduction wiremock
この入門ビデオチュートリアルでは、Wiremockの機能と、WiremockをスタンドアロンサーバーおよびJUnitテストの一部として実行する方法について説明します。
このチュートリアルでは、Wiremockツールに関する基本的な概念と詳細について説明します。スタンドアロンのHTTPサーバーとしても、要件に応じてJUnitテスト内でも使用できます。
これはオープンソースであり、貢献者の素晴らしいコミュニティがあるため、頻繁に使用されるツールです。これは、サービス仮想化ツールのカテゴリに分類されます。
学習内容:
ワイヤーモックとは何ですか?
簡単に言うと、Wiremockは統合テストのモックセットアップです。これは、特定のリクエストに対して期待される応答を返すように高度に構成可能な単なるモックサーバーです。
これは、開発中、さらに重要なことに、システムまたはサービスが1つまたは複数の外部または内部の依存関係/サービスと通信する統合テスト中に広く使用されます。
一般的な統合テストについてもっと理解し、Wiremockがこれらの課題を乗り越えて私たちの生活を楽にするのにどのように役立つかを理解してみましょう。
一般に、統合という言葉が出てきたとき、私たちを驚かせるのは、2つの通信システム間のエンドツーエンドの統合です。それでは、外部サービスを使用してジョブを実行するテスト対象のアプリケーションの観点から見てみましょう。
例えば、 オンライン旅行またはチケットシステム用のアプリケーションを構築していて、インド鉄道が提供する外部APIにアクセスするPNRステータスチェック用のモジュールがあるとします。
では、アプリケーションを外部APIと統合テストするにはどうすればよいでしょうか。
これを行うには2つの方法があります。
- 最初、 はユニットテストアプローチです。このアプローチでは、提供された(または社内で作成された)インターフェースをスタブ化して、外部APIにアクセスする前でも、スタブ化された応答または偽の応答をシステムがテスト/検証します。これは、外部依存関係をモックしようとする単体テストに他なりません。
- 2番目 は、外部依存関係のテスト環境(または実際の実稼働環境)でテストしています。ただし、そのアプローチには、以下に示すようないくつかの課題があります。
- 外部APIシステムが常に利用できるとは限りません。つまり、外部システムに大きく依存または依存しており、そこでのダウンタイムはテストに影響を与え、間接的に開発/リリースプロセスに影響を与えます。
- 次に、外部APIにはテスト環境がある場合とない場合があります。 例えば、 PNRステータスチェックAPIは、応答をフェッチして返すために常に実際のPNR番号を必要とする場合があります。
- 多くの場合、APIのヒットにはコストがかかります。 例えば、 PNRチェックAPIが1000リクエストごとに100ルピーを請求するとします。統合テストは通常、すべてのリグレッション中に(そしてほとんどの場合すべてのコミットで)実行されるため、テスト目的でもコストがかかるようなAPIをヒットすることは費用効果の高いソリューションではない可能性があります。
- 目的の応答を返すように外部APIを構成することはできません。可能であっても、さまざまなリクエスト入力に対してさまざまな応答を確認するために、多くのテストデータを作成する必要があります。
例えば、 APIがさまざまなタイプのデータに対してさまざまなステータスコードを返すなどのエラーシナリオをテストする必要があります。応答は制御できないため、考えられるさまざまなシナリオまたは結果を検証するために、複数のデータセットを作成する必要があります。
下の図を参考にして、これらの概念を理解しましょう。
ここでは、統合テストの両方のアプローチを比較しています。つまり、外部依存関係の実際の実装を使用するモックサーバーなしと、依存関係に対して受信した要求への応答をモックするモックサーバー(Wiremock)を使用します。
後者の場合、依存関係と依存関係の実際の実装への依存を大幅に減らし、品質と配信スケジュールを犠牲にすることなく多くの構成機能を提供します。
Wiremockは特定の要求にどのように応答しますか?
ご存知のとおり、Wiremockはプログラムによるモックサーバーです。特定のリクエストに応答する方法は、関連するすべてのマッピング(またはモックされた応答)を「mappings」という名前のフォルダーに保存することです。
着信リクエストを保存されたマッピングに照合するWiremockのマッチャーコンポーネントがあり、一致が成功した場合、最初のそのような一致が指定されたリクエストの応答として返されます。
スタンドアロンバージョンのWiremockを使用している場合、Wiremockサーバーを実行すると、Wiremockのインストール/ jarロケーションディレクトリに作成されるマッピングフォルダが表示されます。
ビデオチュートリアル:Wiremockツールの概要
最高の無料のYouTubeダウンローダーは何ですか?
ワイヤーモックの使い方は?
それでは、このツールを統合テストでどのように使用できるかを見てみましょう。
以下のように使用できます。
スタンドアロンのWiremockサーバー
スタンドアロンサーバーとして、WiremockのMaven / Gradle依存関係を持つ単純なJavaアプリケーションを作成し、それを実行中のプロセスとして保持することができます。
これは、スタンドアロンサーバーを特定のマシンでホストし、プロジェクト全体またはチーム全体の単一のモックサーバーとして使用する場合に適した代替手段です。スタンドアロンモードでは、利用可能なスタンドアロンjarをダウンロードすることにより、このツールを実行することもできます。 ここに 単にjarファイルを実行します。
例えば、 Wiremockスタンドアロンインスタンスをクラウド上のサーバーまたはオンプレミスサーバーにデプロイする場合は、このjarを実行し、システムIPを使用してホスト型サービスとして使用できます。
いくつか見てみましょう これをスタンドアロンモードで実行する手順(およびポート、マッピングフォルダーなどのさまざまな構成)
#1) 他のJARファイル(Wiremock jarインストールディレクトリから)と同様に、ターミナル(またはWindowsユーザーの場合はコマンドプロンプト)からWiremockjarを実行します。
java -jar wiremock-standalone-2.25.1.jar
#二) デフォルトでは、Wiremockはlocalhost:8080で実行され(ポートが使用可能である場合、上記のコマンドはWiremockサーバーをスタンドアロンモードで起動します)、次のような出力が表示されます。
#3) サーバーが起動すると、localhost:8080の任意のURLにアクセスできます。
例えば、 http:// localhost:8080 / get / user / 1 –現在、モックが設定されていないため、次のような応答が返されます。
#4) それでは、このURLに単純なスタブ/モックを設定して、URLをもう一度ヒットしてみましょう。次に、同じURLをヒットすると、モックまたはスタブされた応答が返されることを検証します。
curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is!
' }}' http://localhost:8080/__admin/mappings/new
最初にこのCURLリクエストを理解してみましょう。
- http:// localhost:8080 / __ admin / mappings / newに対してCURLPOSTリクエストを行っています。これは、JARファイルを介して実行/開始したWiremockサーバーのすべてのマッピングが保存される場所です。
- Curlリクエストでは、「response」セクションのレスポンス本文とともに、URLやリクエストメソッドなどのリクエストパラメータを定義しています。これは、GETリクエストがURL / get / user / 1で受信されるたびに、指定された応答本文で応答することを意味します。
#5) スタブ応答が設定されたら(上記のcurlリクエストを使用して)、URLをヒットして、Wiremockからスタブ応答が返されるかどうかを確認できます。
ブラウザでこのURLを押してみましょう– http:// localhost:8080 / get / user / 1
マッピングが正常に設定された場合は、次のような応答が返されます。
JUnitルール構成としてのJUnitテストとともに
Wiremockサーバーは、JUnitルールのセットアップとしてJUnitテストで使用できます。これにより、JUnitはWiremockのライフサイクルを処理します。つまり、Wiremockが開始および停止します。
Android携帯用のmp3無料ダウンロード
これは主に、テストのたびにサーバーを起動および停止するセットアップで使用されます。
これには、複数のユーザーが同じサーバーを使用して互いのスタブされた応答をステップオーバーする可能性があるスタンドアロンセットアップとは対照的に、分離されているという独自の利点があり、高度な構成が可能です。
このアプローチの実際の例を見てみましょう。
#1) WiremockサーバーのJUnitルールを作成します。このステップは基本的に、すべてのテストの前にWiremockサーバーをインスタンス化し、すべてのテストの後にサーバーを停止するようにJUnitランナーに指示するテストセットアップステップのようなものです。
これが意味することは、JUnitランナーが明示的に行うことなくWiremockサーバーの起動と停止を処理するということです。
@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080));
#二) 次に、最初にクライアントを作成して(okHttpを使用)、目的のエンドポイントに対してリクエストを実行するテストを記述します。
// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build();
#3) ただし、ここで、Wiremockインスタンスに対して返されるスタブがまだ設定されていないことに気付くでしょう。つまり、上記のクライアントは、スタブが構成されていないURL http:// localhost:8080 / test / abcを要求します。この場合、Wiremockサーバーは404noコンテンツを返します。
#4) ここで、Wiremockサーバーインスタンスの上記のURLにスタブを設定するには、以下に示すように、Wiremockのスタブ静的メソッドを呼び出す必要があります。
private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); }
ここでは、configureFor、stubForなどの静的メソッドをいくつか使用したことがわかります。これらのメソッドはすべてWiremockJavaライブラリの一部です。 (これらの方法については、次のチュートリアル/セクションで詳しく説明します)
#5) 構成手順が完了したら、クライアントを介して要求を実行し、応答を検証するだけです(スタブがWiremockを介して戻るように構成されているものに応じて)
要約すると、コードサンプル全体は次のようになります。
public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } }
必要な依存関係
それは次のように利用できます:
- Wiremockの依存関係のみを含むスタンドアロンJAR。
- Wiremockとそのすべての依存関係を含むファットジャー。
どちらのフレーバーも、GradleとMavenの依存関係として利用できます。詳細については、公式のMavenリポジトリをご覧ください。 ここに
ビデオチュートリアル:JUnitテストを使用したワイヤーモック
結論
このチュートリアルでは、Wiremockの基本機能について説明し、Wiremockをスタンドアロンサーバーとして、およびJUnitルールを使用したJUnitテストの一部として実行する方法を確認しました。
また、スタブについても簡単に触れました。これについては、次のチュートリアルで詳しく説明します。
次のチュートリアル