Web API、Webアプリ、モバイルWebのテスト方法を披露
Mobageオープンプラットフォームアーキテクチャの中で、SWETグループがテスト対象としているのは次の4つである。
- Mobage RESTful API（Web API）
- Mobage Developers（Webアプリケーション）
- mbga.jp＆ProxyServer（モバイルWeb）
- Mobage SDK（クライアントSDK）」
「チーム立ち上げ時に、私たちはエンド・ツー・エンドのテストの確立という目標を掲げた。これらはいずれもユーザーに一番近いところ。だから、ターゲット（テスト対象）とした」（中川氏）
Mobage RESTful API（Web API）
では、具体的にどのようなテストを行っているのか。最初に中川氏が紹介したのは、Web APIのテストである。Web APIのテストでは、APIサーバーとHTTPで通信してテストを行うが、テストクライアントはAPIサーバーやデータベースなどと同じセグメントに置く構成をとる。これにより、データベースやキャッシュのデータを、テスト中に参照したり変更したりすることを可能にしている。
SWETグループでは、これを「Gray Box Fixture」と呼んでいる。テスト自体はブラックボックスで行いながらも、テストの条件を作るところはホワイトボックスで行う。特にWeb APIでは、この「グレーボックス」を重視していると中川氏は語る。
その他にも、テスト用にDNSサーバーを利用して特定のサーバー1台をテスト対象にしたり、Web APIのドメインに特化したクライアント (Domain Specific Client) である「mobage-api-client」を作成したりして、テストを行っている。また、HTTPの通信内容をダンプできるようにしたり、テストを対話実行できるようにして、テスト中でのデバッグを可能にしているとのことだ。
Mobage Developers（Webアプリケーション）と
mbga.jp＆ProxyServer（モバイルWeb）
WebアプリケーションやモバイルWebに対するテストは、ブラウザ上で行っている。先述のWeb APIのテストと異なるのは、UIやJavaScriptを多用している点である。
Webアプリケーションのテストは最近のデファクトに忠実で、ツールとして「Selenium WebDriver」を採用。高速化のため、Headlessブラウザも使用している。
特徴的なのは、「ブラウザとエミュレータを使い分けてテストしている点」と中川氏。ブラウザでは、一般的にHTTPヘッダは取得できない。一方、mechanizeのような方法では、HTTPヘッダは取得できるが、JavaScriptの解釈ができないことが多い。そこでブラウザの状態を保存し、ブラウザとエミュレータを自動的に切り替える工夫を施しているという。そのほか、ここでもDomain Specific Clientである「mobage-browser」というライブラリを作成して、テストを実施している。
また、UIテストではPage Object Patternを使っていない。モバイルエミュレーションについては、今はリアルデバイスを使う方向に動いており、「CalabashやAppiumなどに手を出していこうとしている」（中川氏）。
Mobage SDK（クライアントSDK）
クライアントSDKのテストについては、「実際に自分たちでSDKを使ったアプリを開発し、そのアプリ操作を自動化するテストを実行することで、SDKがちゃんと動いているかをチェックする方法でテストをしている」（中川氏）という。UIオートメーションに関しては、複数のデバイスでもテストケースに一貫性を持たせられるよう、「Calabash」や「Appium」を利用。Calabashによるテストについては、自身も執筆に参加した「『WEB+DB PRESS vol.77』（技術評論社刊）の特集1『スマートフォンテスト最前線』をぜひ読んでほしい」と述べた。
最後に中川氏は、Domain Specific Clientの強みを生かしたテストの例を示した。例としたテストの対象と内容、およびテストシナリオは次のとおりである。テストシナリオは、（中川氏があまり好きではないという）Cucumberで書かれている。
●テスト対象
「ゲームから送られるブロードキャストの通知に対し、ユーザーが、モバゲーチャットでnotificationを受け取るか受け取らないかの設定を、モバゲーのサイトから変更する」という機能
●テスト内容
❶ 「ユーザーがログインし設定ページでnotificationの受け取りを有効にすると、notificationのブロードキャストが飛んできて、そのメッセージを確認できる」こと
❷ 「ユーザーがログインし設定ページでnotificationの受け取りを無効にすると、notificationのブロードキャストが飛んできても、そのメッセージを表示しない」こと
●テストシナリオ
Feature: Notification from Games
Scenario: User can receive notification
Given user login to mbga.jp
When user visit to settings page
And user enable to “notification” setting
And game broadcast notification using API
And user visit to Mobage Chat page
Then user can show notification message
Feature: Notification from Games
Scenario: User can ignore notification
Given user login to mbga.jp
When user visit to settings page
And user disable to “notification” setting
And game broadcast notification using API
And user visit to Mobage Chat page
Then user can not show notification message
このシナリオには登場人物としてuserとgameがいるが、それぞれのテストコードの実装に、mobage-browserおよびmobage-api-clientというDomain Specific Clientを使っている点がポイントである。これにより、APIとWebをまたがる結合テストが容易に実装できている。「ここに、Domain Specific Clientにこだわってやってきた利点が出ている。コンポーネント単位のエンド・ツー・エンドのテストから、複数のコンポーネントを対象とするシステムテストまで、クライアントを再利用できるメリットがある」（中川氏）。
全体として、事例や実際に活用しているテスト技術に踏み込んだ密度の濃いセッションであった。
