概要編その２

今回はその１で紹介した方法とは別の方法で Mock の作成と登録をしてみたいと思います。

Mock の登録方法

まず Mock の登録方法は２種類あります。
１つ目は前回紹介した WireMock API を用いて登録をする方法
その１では画面上からポチポチしましたが、説明にあったとおり curl 等でアクセスし登録することが可能です。

そして今回紹介するのは、指定されたディレクトリに直接ファイルを置く方法です。
※前回の続きの体で続きますので、導入から行う場合はその１を参照してください。

ディレクトリ探索

まずは WireMock の立ち上げによって生成されたディレクトリを探しましょう。
最終的に探し出す必要のあるディレクトリは__filesとmappingsです。
大体 jar ファイルと一緒に置いてあることが多いです。
現場で使用していた PC は以下の構成で生成されていました。
/wiremock-standalone/libexec/wiremock-standalone-2.23.2.jar
しかし、私用 PC ではユーザー直下にディレクトリが生成されていました。

$ ls ~
__files mappings
Desktop eclipse etc..

環境により異なるようなので、findコマンドでガツッと全検索しても良さそう。
→現場では jar ファイルを直接起動していましたが、同じように homebrew の力を借りてみたところ ~ ディレクトリ直下に生成されていました。homebrew ほんと便利

mappings

まずは mappingsから。
こちらは Mock の設定ファイルを配置する場所になります。
前回、画面上から Json 形式のものを登録しましたが、これをファイルとして mappings に置くことで Mock の登録ができます。

前回のこれを…

ファイルとして保存！

では出来上がったファイルを mappingsディレクトリ直下に置いてみます。

$ ls mappings
wiremock_sample.json

これで準備OKです。
せっかくなので今回は curl でアクセスしてみましょう。
それではまず WireMock を起動して…

curl で先程の Mock を呼び出します。

$ curl -X GET http://localhost:8080/some/thing
Hello World!

上記の通り Hello World!の文字が出れば成功です。
せっかくなので画面からも確認してみましょう。
下記の URL にアクセス…
http://localhost:8080/__admin/swagger-ui

そのまま GET /__admin/mappingsの API を起動してみましょう。

登録されていることが確認できればOK

※注意してほしいのがこの方法で Mock を作成、配置した場合は WireMock の再起動が必要になります。
後述で Mock を再配置しますが、その場合は WireMock の再起動をするようにしてください。

__files

Mock の応答値の設定では以下のようなパラメータがあります。

要はレスポンスボディに含めるパラメータを直接入れるのではなく、ファイルから参照します、というものです。
この参照ファイルの置き場というのが、__filesディレクトリになります。
試しに上記のファイルを置いてみましょう。
以下のファイルを作成します。

これを __filesディレクトリの直下に置いてみます。
ついでに先程の設定ファイルも mappingsディレクトリ直下に移動…

$ ls mappings
wiremock_sample.json
$ ls __files
response_sample.json

これで準備OKです。
それでは Mock を呼び出してみましょう。

$ curl -X GET http://localhost:8080/some/thing
{
  "sample":"wiremock"
}

先程設定した Json が帰ってきたらOKです。

ファイル配置におけるメリット・デメリット

今回と前回で２つの方法を紹介させていただきました。
それぞれの方法でのメリット・デメリットは以下のとおりです。

	API	ファイル配置
①WireMockの再起動	必要ない	必要
②ディレクトリ構成の自由度	[mappings]及び[__files]直下のみ	自由
③設定ファイルに複数のMockを記載できるかどうか	不可	可能

①に関しては冒頭で述べましたが、他の項目も簡単に紹介します。

②ディレクトリ構成の自由度

今回の説明で私は[mappings]の直下に設定ファイルを。
[__files]の直下にレスポンス情報を持つファイルを置くと説明しましたが、少し違います。
正確にはそれらのディレクトリより下に存在していれば WireMock は正常に読み込んでくれます。
そのため、ファイル配置における管理にする場合は、ディレクトリ別に設定ファイルの整理をすることができます。

以下のディレクトリ構成なら…
/__files/test/response_sample.json

レスポンスの該当項目はこう設定します。
"bodyFileName": "/test/response_sample.json"

一方、API での登録の場合です。
説明はしていませんでしたが、実は API で登録することで、受け取った Json の情報から設定ファイルを勝手に作成してくれています。
※前回の API の後に save API を叩く必要があります。

しかし、ディレクトリの指定をすることはできません。
レスポンスファイルについては、そもそも登録する API が用意されていないため格納することができません。

そのため、ディレクトリを用いての設定ファイルの管理をしたい場合は[ファイル配置]のが良いでしょう。

③設定ファイルに複数のMockを記載できるかどうか

[ファイル配置]でやる場合は以下のとおりです。

{
 "mappings":[
  {
   "request":{...},
   "response":{...}
  }
 ]
}

通常の設定ファイルを mappingsで配列とすることにより、それぞれの Mock の内容を読み込んでくれます。

一方 API の場合はどうでしょう。
確かに複数の Mock を同時登録することは可能です。

POST /__admin/mappings/import
あとは先程と同じ形です。
{
 "mappings":[
  {
   "request":{...},
   "response":{...}
  }
 ]
}

リクエストしている内容は前者と同じですが、API の場合だと、mappings の中の設定を分割し、ファイルとして吐き出してしまいます。
つまり mappings の配列のサイズが複数存在するのであれば、その数だけ設定ファイルが生成されてしまうのです。
それを良しとするかどうかは人、あるいは現場によりけりといったところでしょうか。

〆

いかがだったでしょうか
ざっくり扱い方を2回に分けて解説しました。
なんだかんだ敷居が低く、サッと使えるので中々悪くないのではないのかなと思っています。
今後お世話になることもあり得るかもなので、ちょいちょい調査していこうと思います。

（概要編と書いたけど続きは…）

WireMock を調査してみた 概要編 その２

概要編 その２