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

# 概要編 その２
その１はこちら
[WireMock を調査してみた 概要編 その１](https://qiita.com/startPG/items/3304a63243f56bf77a95)

今回はその１で紹介した方法とは別の方法で 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 の登録ができます。

前回のこれを…
<img width="1440" alt="スクリーンショット 2019-07-16 23.50.06.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/fbe4c330-f319-e7af-b728-8f2fd2bb659d.png">
ファイルとして保存！
<img width="337" alt="スクリーンショット 2019-07-20 8.18.57.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/4151b370-604b-1659-db59-43d07302c3c2.png">

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

```
$ ls mappings
wiremock_sample.json
```
これで準備OKです。
せっかくなので今回は `curl` でアクセスしてみましょう。
それではまず `WireMock` を起動して…
<img width="578" alt="スクリーンショット 2019-07-16 23.40.36.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/5a22da7b-d9cd-e5c6-a4de-26303ea56d42.png">
`curl` で先程の Mock を呼び出します。

```
$ curl -X GET http://localhost:8080/some/thing
Hello World!
```
上記の通り `Hello World!`の文字が出れば成功です。
せっかくなので画面からも確認してみましょう。
下記の URL にアクセス…
http://localhost:8080/__admin/swagger-ui
<img width="1440" alt="スクリーンショット 2019-07-16 23.44.28.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/42d45165-ebfc-dacc-deda-6c1918b05702.png">
そのまま `GET /__admin/mappings`の API を起動してみましょう。
<img width="1440" alt="スクリーンショット 2019-07-16 23.54.06.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/b1efc6c5-f75d-e01a-151d-1b12505904ad.png">
登録されていることが確認できればOK

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

## __files
Mock の応答値の設定では以下のようなパラメータがあります。
<img width="329" alt="スクリーンショット 2019-07-20 8.48.23.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/332459b9-18d4-b4e3-b712-b13acce05365.png">
要はレスポンスボディに含めるパラメータを直接入れるのではなく、ファイルから参照します、というものです。
この参照ファイルの置き場というのが、`__files`ディレクトリになります。
試しに上記のファイルを置いてみましょう。
以下のファイルを作成します。
<img width="224" alt="スクリーンショット 2019-07-20 8.51.59.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/269525/45e6fc4d-3962-f52a-a81d-b651a6543db3.png">
これを `__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回に分けて解説しました。
なんだかんだ敷居が低く、サッと使えるので中々悪くないのではないのかなと思っています。
今後お世話になることもあり得るかもなので、ちょいちょい調査していこうと思います。

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