Mobageオープンプラットフォームのテストについて 第2話〜WebAPIのテスト〜

icon2.jpg

みなさまこんにちは。SWETグループの @ikasam_a です。

前回は SWETとは!? と題して、SWETの定義やグループの立ち位置、取り組みなどを簡単にご紹介させていただきました。今回から、SWETグループで実際に行っているテストの取り組みについて、Mobageオープンプラットフォームの事例を交えて紹介していきます。

今回は、Mobageオープンプラットフォームで提供している RESTful API について、どのようなテストを行っているか紹介します。

 

RESTful API について

RESTful API とは、Mobageオープンプラットフォームの各種機能を利用するための Web API です。ゲームサーバから、MobageプラットフォームのAPIサーバにHTTPでリクエストを送ると、JSON形式でレスポンスが返ってきます。利用できる機能には、ユーザデータの参照、リーダーボードの利用、リモート通知の利用などがあります。

Mobage Developers Documentation Centerには、ブラウザゲームでAPIを使う場合のフローや、アプリでAPIを使う場合のフローなど、APIを扱うための参考情報が色々載っているので、開発の参考にしてもらえればと思います。

image1.png

また、RESTful API はスマートフォンやフィーチャーフォンなど各種デバイス向けに提供していて、もちろん上記 Documentation Center に各種デバイス用のリファレンスがあるので、こちらもあわせてご参照ください。

 

WebAPI のテスト戦略

WebAPIにはUIが無く、HTTPのリクエストベースで処理が完結するため、テストもシンプルに考えることができます。

私たちのWebAPIテスト戦略もいたってシンプルで、APIサーバとHTTPで通信できるテストクライアントを作成し、システムの裏側のDBやキャッシュのデータも考慮しながら、様々な条件でリクエストを送り、レスポンスをチェックする、という非常にシンプルな考え方になっています。

image2.jpg

 

“Domain Specific Client” の活用

重要なポイントの1つとして、テストクライアントをどこまで作りこむかという話があります。クライアントに必要な最低限の要件は、HTTPでリクエストを送れることなのですが、あまりにもクライアントが単純な薄い作りになっていると、テストコード中にHTTP周りの処理やAPIリクエストの共通処理など、テストの観点からは重要ではないコードが混ざってしまいます。

私たちは、「何をテストしているのか」が極力わかりやすいようにテストコードを書くことを重視しています。そのためテストクライアントでは、ある程度まとまったHTTPの処理や、RESTful API 群のドメイン知識に基づく共通ロジックなどを、隠蔽して実装しています。こうして作った高機能クライアントを使うことで、テストコード自体は、テストに特化したクリーンな状態が保てるようにしています。


なお、私たちは、このようにドメイン特化した高機能クライアントのことを “Domain Specific Client” と呼んでいます。この “Domain Specific Client” はテストだけではなく、簡単にAPIにアクセスできるデバッグツールとしても利用しています。

APIに特化したクライアントをテストから分離していることで、テスト以外で利用できるのもそうですし、あるいはAPIと他のコンポーネントの結合テストといった、違うレイヤーのテストにおいてもクライアントを使いまわすことができるというメリットがあります。

 

テスト条件の作り込み

先ほど「システムの裏側のDBやキャッシュのデータも考慮しながら、様々な条件でリクエストを送り」と書きましたが、リクエストパラメータの正否のみを考慮した単純なテストだけでは、APIに特化したテストの条件としては不十分です。

APIを利用するユーザやゲームの状態によって、あるいはAPIと連携しているMobageオープンプラットフォームのシステム状態によっても、APIレスポンスは変化します。特に、システム側のDBやキャッシュの状態に依存して決定されるテスト条件もあります。

image3.jpg

ユーザやゲームが直接関与できないテスト条件を作るために、私たちのテストではDBやキャッシュを操作しながらテストする方法をとっています。具体的にはテスト開始時にDBやキャッシュに特定のデータを設定したり、テスト中にもDBやキャッシュを動的に変更したりします。私たちは、この方法を “Gray Box Fixture” と呼んでおり、テスト環境の同一ネットワーク内に、DBとキャッシュ、そしてテストクライアントを配置することで実現しています。

 

柔軟なテストのために

上記で紹介したことの他に、テストを柔軟・円滑に行うために取り入れている仕組みを紹介します。

 

特定サーバ向けのテスト

Mobageオープンプラットフォームでは、RESTful APIには決まったドメインが割り当てられ、パフォーマンスの観点からAPIサーバ群をクラスタ構成で運用をしています。こういう状況において、ある特定のAPIサーバだけに変更を反映してテストしたいという要求があります。

この問題を解決するため、私たちは2つの方法を取り入れてきました。

  1. テストクライアントで名前解決を動的に行い、テスト実施時に任意のアドレスを参照するように差し替える

  2. テスト実行環境にDNSサーバを構築し、テスト中からDNSエントリを書き換えて任意のアドレスを参照させる

1つ目の方法は、テストクライアントのみで解決する方法ですが、テストクライアントにある程度のロジックが必要になります。

2つ目の方法は、テストクライアントから名前解決のロジックを切り出すことができますが、実行環境のDNSを書き換えるため、プロセスを超えてテスト全体に影響を及ぼす点に注意が必要です。

 

対話モードとデバッグモード

通常自動テストでは、一度実行すると最後まで止まること無く動き続けるわけですが、特定の部分で実行を止めてデバッグしたいという要求も出てきます。またこのときに、クライアントが送ったリクエストとAPIのレスポンスがわかると、デバッグ作業も捗るので、対話実行する interactive モードと、HTTPメッセージをすべて出力する debug モードを導入し、on/off を切り替えながら組み合わせて使えるようにしています。

 

最後に

今回は、私たちがどのような戦略や仕組みでWebAPIのテストをしているかを紹介しました。

テストするのが比較的簡単で、かつ単純に思えるWebAPIのテストですが、テストの仕組みにちょっとした工夫をすることで、テスト以外の場面での活用や、テストそのものを捗らせたりと、色々な可能性が広がります。ただ盲目的にテストするだけではなく、多角的にプロダクトやサービスの品質保証・品質向上をしていくための参考になれば幸いです。