APIモックとサービス仮想化ツールであるWireMock v2がリリースされた。中心となる改良点は、改善されたリクエスト検証失敗レポート、(Java 8のラムダの使用を含む)カスタムリクエストマッチングロジックを作成する能力、gzip圧縮されたリクエスト及びレスポンスボディのサポート、ランダムに分散された遅延(現在は一様分布と対数正規分布がサポートされている)、そしてcookieとbasic認証ヘッダのマッチングを含む。
InfoQはWireMockの作者であるTom Akehurst氏と同席し、WireMock v2の新機能、モダンなアーキテクチャにおけるサービス仮想化が果たす役割、そしてモックと契約の検証との関係について質問した。
InfoQ: どうもTomさん、InfoQへようこそ！簡単な自己紹介とWireMockとは何かを教えて頂けますか？
Akehurst氏: こんにちは！私はTom Akehurstです。日中はロンドンでよりよい技術の構築に関して精力的にクライアントを支援し、夜(と週末)にWireMockをメンテナンスしています。
WireMockはAPIモック、もしくはサービス仮想化のツールであると紹介したいと思います。本質的にはアプリケーションが依存するシステムとのHTTPのやりとりをテストのためにスタブ、もしくはモックすることができるものです。以下にいくつかの利点を挙げます。
- 依存しているAPIが未完成、もしくは存在しないときでも生産性を維持できます。
- テスト環境や第三者のサンドボックスへの依存を軽減できます。
- 実システムを用いたテストと比較して高速なテスト実行ができます。(10倍以上の高速化が可能)
- TCP接続の切断や突発的な遅延のような泥臭いケースを含む、境界ケースと例外系のテストが容易に行えます。
ドキュメントと他の情報はhttp://wiremock.orgで確認することができます。
InfoQ: WireMockの最近のv2リリースで導入された新機能について教えて頂けますか？
Akehurst氏: WireMock v2はスタブ定義とリクエストの間に"距離"の概念を導入しました。このことにより、マッチしなかったリクエストと検証失敗時のレポートを大きく改善することができました。検証呼び出しがリクエストのマッチに失敗したとき、WireMockは一番近いものを発見してdiffを提供することが出来るようになりました。このことは労力を大きく削減します。例えば、多数のHTTP POSTに関連した機能をテストするときに一つの文字を大文字にすることを忘れていたことを発見できます。
拡張APIもリッチになりました。レスポンストランスフォーマはパラメータを引数に取ること、プロキシされたレスポンス変換することができるようになりました。カスタムレスポンスマッチングロジックも使えるようになり、Java 8ラムダ経由でも使用できます。
WireMock 1.xもAndroid上で動作させることができましたが、動作させるためにはライブラリの非互換性のワークアラウンドのために少しソースを変更したフォーク版をメンテナンスすることが必要でした。Androidコミュニティの数人が助けてくれたおかげで、ビルドファイルに数行付け加えるだけで動作するようになりました。
他の特記すべき変更点は以下です。
- gzip圧縮されたリクエスト及びレスポンスボディのサポート
- ランダムに分散された遅延。現状は一様分布と対数正規分布がサポートされています。
- cookieとbasic認証ヘッダに対するマッチ
- スタブマッピングの編集・消去及び(再)保存
- Jetty 9へのアップグレード。これによりパフォーマンス向上、ServletAPI依存問題の軽減とバグ修正が図られます。
- 標準・スタンドアロンJARのMavenアーティファクトとの分離。これにより、スタンドアロンJARに依存したい場合に推移的依存関係に含まれる成果物を除外せずに済むようになりました。
InfoQ: あなたの考えではどれくらいの開発者が(モックやスタブに比べて)サービス仮想化技術に関心があるでしょうか？また、WireMockのようなツールが優れているユースケースの具体例を教えて頂けますか？
Akehurst氏: Googleトレンドを少し見たところだと、MockitoはWireMockの検索回数の約10倍ですので、(あまり科学的でないところもありますが)サービス仮想化の認知度はオブジェクトモックに追いつく途上だというのが妥当なところでしょう。
しかしWireMockのようなツールへの興味はここ1,2年で急激に上昇してきています。この現象に対する説明の一つとしてはマイクロサービスの知名度の急激な上昇があります。マイクロサービスのテストの準備に使用しているWireMockのユーザは増加しており、この領域が間違いなくスイートスポットだと言えます。
WireMockが高い価値を付与できる他のユースケースとしては以下のものがあります。
- コンポーネントテスト - ユニットテストに近い速度で単一のサービス・アプリケーションに対する受け入れテストを実行する。オブジェクトモックによりシステム境界の置き換えができますが、WireMockを使用すればHTTPクライアントやリソースプール、シリアライズ/デシリアライズが全て対応できます。
- 例えばソケットの未接続状態など、障害シナリオへの対応。これらはオブジェクトモックツールでは正確に再現するのがとても難しく、実システム上で模倣するのも同様に困難です。
- 隔離されたパフォーマンステスト - 単一のコンポーネントのパフォーマンスを計測する。ここでもまた、オブジェクトモックはシステム境界を置き換えることができますが、この結果はHTTPクライアント、コネクションプール、スレッド構成の影響を無視した形に歪曲されます。
InfoQ: WireMockのようなサービス仮想化ツールを用いてテストを作成する際のベストプラクティスを教えて頂けますか？BDDのような、WireMock駆動のテストを補完する方法論はなにかありますか？
Akehurst氏: WireMockユーザとの会話とクライアントとの業務で学んだことが少しあります。
- UI自動ツールのような記録/再生ツールの使用は控えめにすること。度々すぐに変わってしまう事象を記録すると大量の維持コストが発生します。
- UIテストのために作成したページオブジェクトの数と同じくらい、スタブや検証コード周辺にビルダやサービスラッパを作成すること。これは最初は手間が掛かりますが、長い期間で見ると維持や読みやすさの面から役に立つでしょう。
- フォルトインジェクションテストを作成すること - セッションの切断や5xxのレスポンス、ソケットタイムアウトを引き起こす遅延の付加など。夜中にあなたを叩き起こすような問題を捕まえるだけでなく、動作が正常かの確認や監視を行うこともできます。もしJVM(もしくはAndroid)上で実行しているなら、ユニットテストと同様の速度で全方位のサービス回復に関するリスクへのフィードバックを受け取ることができます。これは障害を報告しようと待ち構えるchaos monkeyを確実に打ち破るでしょう！
WireMockはBDDツールと組み合わせてもうまく使えます。私が見たことも使用したこともある良い方法としては、シナリオの"Given"の部分でスタブを設定し、それから"Then"の部分でやりとりを検証するやりかたがあります。
InfoQ: サービス仮想化は契約駆動開発とどのように関係すると思われますか？これらはどこか重なりあうところがあるでしょうか？
Akehurst氏: 私も最近になって考え始めたところですので責任をもって多くを主張できませんが、機械が解読可能な仕様(例えばSwaggerやRAML)はスタブ定義と実態との乖離を検知する問題を解決するためのとても有力な手段に思えます。
興味のあるアプローチとしては、他にSpring Contract Verifierを使用することがあります。これは、クライアントが隔離してテストできるようにするために契約の仕様からWireMockスタブ定義を生成するものです。
InfoQ: WireMockのようなツールは非機能要件のテストに対しても有効だとお考えでしょうか？
Akehurst氏: もちろん！パフォーマンス、回復性、セキュリティといった特性については私はWireMockを使用してテストしていますし、テストされていることを見たことがあります。
例を挙げると、先に挙げたランダムな遅延機能はWireMockを使用しているチームが作成したプルリクエストが元になっており、彼らのマイクロサービスの継続的パフォーマンステストを行うためのものでした。彼らのデリバリパイプラインは、共有環境に移行する前に、各サービスが隔離された環境でのパフォーマンスベンチマークを通過していることを保証しています。
回復性の観点では、アプリケーションを第三者のシステムがプロキシエラーを返却したときにコネクションプールが徐々にリークする、というデモするためのテストを、フォルトインジェクションにより書いたことがあります。
InfoQ: WireMockのWebサイトではMockLabというSaaSを作成したことに触れられています。InfoQの読者にもう少し詳細を教えて頂けますか？
Akehurst氏: 最近、私はWireMockを一からセットアップする際にどんどん複雑さが増す状況に直面しています。また、WireMockのインスタンス群を配置・管理するためにかなりの労力を費やし、予備的なテストとデモを補助するために専用のUIを構築している状況を認識しています。
MockLabはWireMockインスタンス群を管理するための努力を劇的に削減し、数クリックでモックサービスを配置可能とすることを目的としており、テストのセットアップやコードに直接関わらない人々へ解析結果を公開することもできます。
もしモバイルアプリ、マイクロサービスや第三者のAPIに依存したシステムを構築(もしくはテストを！)しているのであれば、一度確認していることを強くお勧めします。
より詳細な情報を知りたい場合やMockLabが使用可能になった時に通知を受け取り場合は、稼働準備中のページ(http://get.mocklab.io)を確認してください。
IInfoQ: 本日はInfoQのためにお話し頂きありがとうございました。Tomさん、何か他に読者に伝えたいことはありますか？
Akehurst氏: v2をリリースするために支援して下さった全ての方々にお礼を言いたいです。完全な製作者一覧はhttp://wiremock.org/about/にありますが、特に時間と根気を提供してくれたSam Edwards氏、Rob Elliot氏、そしてRowan Hill氏を挙げたいと思います。みんな、お疲れさまでした！
WireMock v2に関する追加情報はプロジェクトのWebサイトで確認できる。また、コードはTom Akehurst氏のGitHubアカウントにアップロードされている。
Rate this Article
- Editor Review
- Chief Editor Action