Hubに公開してみました。Images普段からDockerに慣れ親しんでいる人であれば、イメージを落としてきてAeromockのディレクトリをマウントするだけで簡単にモックサーバの機能を利用できます。Mac環境であればboot2docker環境で利用するわけですが、boot2dockerについてはこの記事の本質じゃないので省略。通常、Aeromockを使うにはaeromock-brewというツールでインストールするんですが、その手間無しに利用できます。使い方サンプルプロジェクトを用意してます。./staticAPIのモックデータ用のディレクトリを掘る(/path-to-path/aeromock/api_root)静的コンテンツのディレクトリを掘る(/path-to-path/aeromock/static)。必要なくても、現状これが無いと動かない(近いうちに直す)ので、.gitkeepでもディレクトリに放り込んでおくテストデータを置く(/path-to-path/aeromock/api_root/test.yaml)。test.yamlで置くので、このモックデータの**エンドポイントは/test**となる。fugaAeromockをDockerで動かすDockerで意識することはマウントするAeromockのディレクトリとポートだけです。dockerコマンドで済ますのであれば以下の通り。stormcat24/aeromockマウント先は/project(ここは変えないように)。個人的にはDockerコンテナのオーケストレーションにはFigを使っているので、以下のようにfig.ymlを用意してFig経由で起動するのが良いかなと。Figだとマウント元のパスを相対パス指定できますし。aeromockCircleCIでCIするせっかくDockerを使ってるので、CircleCIでCIしてみましょう。以下のようなcircle.ymlを用意します。http://127.0.0.1:3183/testmachineフェーズでFigのダウンロードと設定、dependenciesフェーズでFig経由でAeromockを起動します。testフェーズではどのようなテストを実行するかを記述するわけですが、ここではAeromockに向けてcurlするだけにしてます。CircleCIでCIしてみると、データファイルで定義した通りのデータが返ってきてることがわかります。この仕組みを応用すれば、APIを利用するアプリケーションのテストがしやすくなります。grunt-connect-proxyやgulp-webserverのプロキシにAeromockを利用して、ローカルでもCircleCI上でもその環境を意識せずにAPIを利用したテストをすることができるようになります。APIを利用するアプリケーションのテストは難しいわけで・・・APIを利用するアプリケーションの場合、ローカルでも開発環境でもCI環境でもシームレスに連携させてテストを通すようにするのは結構難しいものです。Docker以前の時代では色々な工夫が必要でした。ユニットテスト時にAPIのリクエストを投げないような仕組みにしたり、テスト用のレスポンスを返すようにしたり・・・。(実際にAPIサーバにリクエストしても、そのレスポンスは保証されないし、そもそも死んでるかもしれないし)。これらの苦肉の策による方法はテストを通すためにAPIクライアントのテスト(リクエストやレスポンスハンドリング部分)を事実上放棄してるに近く、このようなテストにはそれほど意義がなくなってしまいます。結合という意味においてはモックサーバを使ったユニットテストにおいてもその意義は問われるかもしれません。APIのインタフェースを取り決めておき、その仕様ベースで開発が動いているのであれば、CIによってクライアント側のコード品質が保たれることは十分に意味があることと考えます。Aeromockを使えばAPI仕様には依存しますが、APIサーバというコンポーネントには依存しなくなるので、利用しているAPIサーバにテストで悩まされるということは無くなります。いうかそういうのはもう無くしましょう。