LivingSocial: SOAのテストとmockの工夫

https://techblog.livingsocial.com/blog/2014/08/26/soa-series-part-5-testing-apps-with-service-dependencies/

1 comment | 2 points | by WazanovaNews 約3年前 edited


Jshiike 約3年前 edited | ▲upvoteする | link

LivingSocialのRailsアプリSOAシリーズの5回目として、サービス指向アーキテクチャにおけるテストのあり方についての話。

まずは、アプリ間のサービスコールを全てmock/stubしたり、逆に依存関係を常にそのまま利用するのではなく、1回だけコールする手法を推薦しています。

テスト対象のコードは、依存するサービスに一度だけコール & レスポンスを記録し、その後の実行ではリプレイを利用する。

  • メリット
    • ネットワークコールが一度で済むので時間がかからない。
    • 実際のサービス環境、APIを反映したテスト結果を取得できる。
    • レスポンスデータが取得できれば、後は、依存するサービスをローカルで実行(時にはインストールも)する必要がなくなる。
  • リスク
    • 依存しているサービスが多い、もしくは大量のデータをリクエストするかたちだと、記録するレスポンスのデータが大きくなる。
    • APIが変更したりするリスクはあるので、どれくらいの頻度で再度記録する必要があるか、判断要。

サービスのレスポンスの記録 & 再生には、VCRを利用。理由は、Railsとのインテグレーションの良さ、簡単な設定、Typhoeusなど様々なHTTP gemと組み合わせることができるから。

一方、mockは、一気通貫のテストができなかったり、APIの変更を検知できない可能性や、テストコードの準備/メンテの手間がかかるというデメリットがあるが、スピードが早いというメリットも依然あり。そこで、サービスアプリのクライアントライブラリにmockオブジェクトを置くことで、リスクを回避する手法も紹介してくれてます。

  • クライアントライブラリをつくる際(LivingSocialの場合はRuby gem)、少なくとも二つのバックエンドを選定できるようにする。一つは、当該ライブラリへのレスポンスオブジェクトを収集するために、対応するサービスへの実際のHTTPコールができるバックエンド。二つ目は、レスポンスオブジェクトを取得するためのネットワークコールは実際にはしないが、替わりに事前に用意されたレスポンスオブジェクトを選択するフェイクのバックエンド。
  • フェイクで設定したレスポンスオブジェクトは、実際のネットワークサービスコールと同じAPIに対応し、mockバックエンドのレスポンスのregistryに事前にロードしておく。
  • テストスイートのセットアップにおいて、テストされるアプリのサービスクライアントライブラリをmockモードとすることで、mockバックエンドに事前にロードされたレスポンスオブジェクトのregistryから、サービスレスポンスが選択される。
  • 非正常系のケースに対応するために、クライアントライブラリは追加でmockレスポンスオブジェクトを生成することができ、必要に応じて、mockバックエンドのレスポンスオブジェクトのregistryから / に対して、追加 / 削除ができる。
  • クライアントアプリが本番環境で実行されている場合は、本番用のクライアントライブラリの設定がなされ、実際のHTTPサービスベースのバックエンドが利用される。

これによるメリットは、

  • mockオブジェクトがクライアントライブラリのバージョンにしっかり対応でき、最新のサービスAPIとやり取りした実際のオブジェクトとの整合性が確認できる。
  • テストのニーズに合わせた、面倒なコード、雛形コードの準備から解放される。
  • mockバックエンドは、事前に設定された標準のレスポンスパターンで構成されるので、テストするコードも追加の設定がいらなくなる。

#livingsocial #soa #rails #ruby #test


ワザノバTop200アクセスランキング


Back