Rails: SOAアプリの結合テスト

http://www.bignerdranch.com/blog/testing-rails-service-oriented-architecture/

1 comment | 0 points | by WazanovaNews 約3時間前 edited


Jshiike 約3時間前 | ▲upvoteする | link

Big Nerd RanchのブログでTravis Douceが、remote_factory_girlremote_database_cleaner を利用したSOAアプリの結合テストについて紹介しています。

まず、DBをもたないクライアントアプリが、user table を持つホームアプリにHTTPリクエストを投げ、JASONリクエストが返ってくるパターンを例としてあげてます。(概念図

よく見かけるのが、

1) クライアントアプリからホームアプリへのHTTPリクエストをスタブする。 2) クライアントアプリのテストを実行する前に、クライアントアプリのテストで必要なデータをホームアプリのDBに用意する。 3) クライアントアプリからホームアプリのAPIにHTTPリクエストを送って、ホームアプリにテストデータを作成する。

というパターンだが、

開発者Aがクライアントアプリ、開発者Bはホームアプリを担当。ホームアプリは /users というパブリックリソースを提供していて、それは全てのユーザのリストを返す仕組みになっている。開発者Aが新機能をつくり、クライアントアプリのインデックスページで全てのユーザの姓を表示するテストを通す。その後、開発者Bはホームアプリのリソース名を /users から /people に変更したことを開発者Aには連絡せず。そして開発者Aは、更に新たな機能を開発して、インデックスページにユーザ数を表示するテストをクライアントアプリで通す。それらの二つの機能が本番環境にアップされる。

という事例の場合、どうなるか?

1) クライアントアプリからホームアプリの /users へのHTTPリクエストがスタブされて、常に全てのユーザのリストが返ってくるかたちになると、クライアントアプリのテストを実行した場合、 ホームアプリのリソース名が /users から /people に変更されてもテストが失敗しない。クライアントアプリ側が、スタブの内容を更新するか、VCRを利用してカセットをレコードしなおせばよい、といっても、人間は物忘れしやすいもの。HTTPリクエストのスタブは、サードパーティのサービスのようにコントロール不可能なときに利用し、自社のテストサーバのようにコントロールできる場合はやらないことをお薦めする。

2) ホームアプリにテストデータが用意されていると、リソース名が変更になった際は、クライアントアプリからHTTPリクエストをしたときにテストが無事失敗してくれる。しかし、テストを続けていくとホームアプリのテストDBを理想の状態に保つのが大変になる。例えば、新規ユーザを作成するテストをクライアントアプリで20回実行すると、ホームアプリのテストDBのユーザが20人増える。このようなパターンが続き、どうしてそのような状態になったのか後からトラックしづらいDBになると、バグを調べるときに難儀するようになる。

3) このパターンもHTTPリクエストの段階でテストが無事失敗してくれるという点では2) と同様。しかし、作成しなくてはいけないデータが複雑な制限や相関関係があったりすると、クライアント側で対処するのが難しくなる。また、パブリックAPI経由ではデータを作成できない仕組みになっているケースもありうる。ホームアプリのAPI経由でテストデータを作成することは、例えばコード(ユーザ登録など)をテストするのが重要な際に、不必要にホームアプリのリソースをテストすることになる。2) と同様にテスト間でのステートがうまく保てないようになる。

解決策

remote_factory_girl と remote_factory_girl_home_rails を利用すると、クライアントアプリでホームアプリのDBにテストデータを作成することができる。そして、remote_database_cleaner と remote_database_cleaner_home_rails で、クライアントアプリはホームアプリのテストDBを削除することも可能になる。

HTTPリクエスト時にリソース名の変更も検知してテストを失敗させることができるのに加えて、

  • remote_factory_girl と remote_database_cleaner は、それぞれ、factory_girl と database_cleaner と、インターフェース及びワークフローが似ているので扱いやすい。
  • factory_girl と同様、remote_factory_girl は、複雑な制限や相関があるデータを作成することができる。
  • remote_database_cleaner と同様、remote_database_cleaner は、テスト間でのデータの管理がしやすい。

GitHubに、このテスト手法を利用したサンプルアプリがあります。

#テスト #rails

Back