More than 5 years have passed since last update.

マイクロサービスのテスト作成方針

Last updated at 2016-06-30Posted at 2016-06-30

そこで、実際にどのように開発していたかを共有する。

今後、おおまかに分けて以下の3つのカテゴリで書いていく。

今回はテストに関してだけで、結構な量になったので、ドキュメント作成とエラー/負荷対策については、今後記載する。

テスト

各サービスごとに単体テストと結合テストを作成した。

結合テストはサービスのプロジェクトとは独立して作成しておき、新しいプロジェクトとして作りなおす場合でも利用できるようにした。(将来的には、Go言語で作り直したい)

だいたい以下のようなフローで行った。

さらに詳細に書くと以下のようになる。

まずはやりたいことを整理して、
引数と、どのようなが必要かまとめる。
先にチェックリストをつくり、本当に実装できているかを最後に確認することで、自分の中でダブルチェックができる。

json-schemeを使い、返り値の型もチェックする。
このjson-schemeはのちほどAPIドキュメントを自動作成する場合にも利用する。

不正なURL, 不正なHTTP METHOD, 不正な引数は最低限チェック。

数値を引数とする場合は、
正負の数, 0, データの境界値(最小 / 最大値), 小数点は最低限チェックする。
これら、必ずテストするものは、1行で呼び出せるよう自動化しておく。

書いてある通り。

今回のプロジェクトでは、各メソッドごとにテストを書いたりしていない。条件分岐がとても多い場合以外は、結合テスト側で各パターンを作ってチェックしている。

理由としては、今後、別の言語でつくるときなどに、再利用できるという点。

逆に、単体テストを作ったのは以下のようなパターン。

作成したコードが規約に則っているか、自動でコードチェック。
PHPの場合は、以下のチェックツールを使う。

Pull request時に、Circle CIで、自動テストを行う。
Circle CIのサーバで、localhostにwebサーバを作成し、単体テスト/結合テストを行う。

複数のプロジェクトで相互に通信を行う場合は、
テストの度にすべてのプロジェクトをcloneし、circle ci環境内でポートを分け、webサーバを立ち上げる。

前述のとおり、今回、APIの結合テストでCucumberを利用した。
デフォルトのCucumberでは、テストが書きづらそうだったので、
以下のgemを改良させて使わせていただいた。
https://github.com/hidroh/cucumber-api

基本、ほぼそのまま利用しているが、以下の点を自分のやりたいことに合うように変更した。