Yamashiro0217の日記スマートフォン用の表示で見るYamashiro0217の日記この広告は、90日以上更新していないブログに表示しています。アプリをテストする方法について学べるようにする。からんだWebアプリケーションのエンドツーエンドの最近のテスト手法についてのまとめにもなっていると思う。最初の3節ぐらいは「Seleniumとは〜」とか「テストってのはさー」とかゴタクをごたごた書いているので、Seleniumの実際のコード見た方がはえぇよ。言う人はコードが出てくるまで記事を飛ばすと良い。こんな記事を気合入れて書いて公開した当日に...FacebookのUIが変わって...作ってたスクリプト動かなくなってしまった...orz。なんなのか簡単に触れる。Webアプリケーションのテストツールである。ボタンをクリックする、リンクをクリックする、チェックボックスを選択する...などを表すスクリプト(JavaやRubyやC#やPythonでかけます)を記述すると、それをSeleniumが解釈し、ブラウザを実際に立ち上げ、スクリプトに従ってSeleniumがブラウザを操作し、Webアプリケーションが正しく動作してるかをテストすることができる。以下のような特徴がある。そのため、単純にはテストをすることが難しい。Http通信をエミュレートするようなテストツールでは、Webアプリケーション全体をエンドツーエンドでテストしたとは言い難い。動作するので、Ajaxのテスト、真にエンドツーエンドのテストができると言えよう。「fooボタン」をクリックするとAjaxで通信が行われ、DOMが操作され、次なる「hogeボタン」が表示される。いうアプリに対してfooボタンをクリックhogeボタンをクリックhogeボタンを押した結果が正しいかをチェックのようなテストシナリオを書いたとする。このシナリオでは「fooボタン」をクリックしたあと、すぐに「hogeボタン」をクリックしようとしてしまうが、実際にはAjax通信したあとに、HTMLが生成され、それがDOMとして描画されないと「hogeボタン」をクリックすることができない。以下のようなシナリオである必要がある。いうシナリオが追加されている。テストの価値について結論から言おう。Seleniumのテストは書いてはいけない。"お前は何を言ってるんだ"って思った人たち。ゴタクにお付き合いください。Seleniumのテストというのは書くのが大変で、かつ実行時間が長い、かつUIというのはすぐ変わる。自動テストというのは闇雲に書いていいものではない。価値の高いテストを書くべきだ。基本はより価値の高い単体テストを先に充実させるべきだ。モダンなWebアプリケーションフレームワークならば、擬似的にHttp通信の代わりとなるテストフレームワークが用意されいると思う。RailsやWicketやCakePHPなどは、Controller層も含めてテストする仕組みが備わっている。単体テストの次はこれらのテストを書くべきだ。側も、DOM操作などのブラウザ依存な部分を切り出し、非ブラウザ(DOM)依存の部分をQUnitなどのJavaScriptの単体テストを実行できるようにしておくべきだ。はいつ書くべきなのか。ブラウザのJavaScript、サーバーサイドの処理、外部APIなども含めたエンドツーエンドのスモークテストマルチプラットフォーム、マルチブラウザな環境でのテスト今回のFacebookのように自分が作ってるWebサービスじゃないサービスを叩くようなアレでそれなどに向いていると思われる。余談だが、Seleniumみたいなブラウザ操作するテストは遅い。JavaScriptがブザウザで動いてることとかもテストしたいという欲求を満たすために、HeadlessなテストをするPhantomJSのようなツールもある。エンジンを使ってブラウザを直接起動しないんだけど、JavaScript+DOMなども含めたテストができるツールである。マルチプラットフォーム、マルチブラウザがターゲットじゃなくてよければそういう解決もありだと思う。今までのコードベースを大幅に変更し、WebDriverというAPI、実装を使った実装に変った。使うようになったので、テストのスクリプトコードも大きく変更されることになった。リリースが最近のことなので、ネットを探してもあまり実際のテストスクリプトコードの情報が見当たらない。いうのがこの記事を書いた動機の一つである。テストスクリプトの例を探すときは、「Selenium」でググる以外に「WebDriver」でググってもいいかもしれない。Facebookのあいさつの返信機能をSeleniumから叩くさて、本題。