JenkinsとSeleniumでJavaScriptのテスト自動化、最初の一歩。第1回 日本Seleniumユーザーコミュニティ勉強会
1月18日に都内で開催された「第1回 日本Seleniumユーザーコミュニティ勉強会」。Seleniumプロジェクトの共同設立者であるJason Huggins氏による基調講演に続いて、有志によるライトニングトークが行われました。
本記事ではその中から、玉川紘子氏による「Jenkins x Selenium 最初の一歩」の内容を紹介します(追記:本記事のタイトルは「JenkinsとSeleniumでJavaScriptのテスト自動化」とありますが、実際の内容は「Selenium RCがJavaScriptの技術を用いて自動テストを行っている」という点がポイントという指摘がありましたので、ここに追記します)。
Jenkins x Selenium 最初の一歩
玉川紘子氏。私はSHIFTというソフトウェアテストの会社で、お客様のプロジェクトに継続的インテグレーションや自動テストを導入する仕事をしています。テスト自動化研究会、日本Jenkinsユーザ会にも所属しています。
Seleniumのテストは作成の手間を考えると、テストを1回実行しただけでは元がとれなくて、何度かテストを実行して元が取れるものです。
そうすると誰かが繰り返しテストを実行しなければなりませんし、繰り返し実行するとしたら結果の確認や実行履歴の管理など、周辺作業も必要になります。仕様が変わればテストも変えなくてはいけません。
なのでチームの意識が高くて、テストをメンテナンスするような基盤が整っていないと、自動化テストの活用はできません。
そこでJenkinsです。これは開発プロセスの中で継続的にビルドやテストを実行してくれるソフトウェアです。
GUI中心の直感的な操作で設定できますので、そんなに詳しくなくても使いこなせます。Seleniumのテストスクリプトを登録しておくと、継続的に実行して結果通知もしてくれるので、周辺作業が楽になります。
SeleniumとJenkinsを組み合わせて使うシステム構成はこんなイメージです。
何らかのバージョン管理システムからJenkinsが最新のコードを取ってきます。Jenkinsはテスト用のマシンにテストをしなさいと命令して、結果を受け取ったらレポートを出すという管理者のような仕事をします。
Jenkinsはプラグインで機能が追加できます。Seleniumという名前が付いたプラグインだけでこれだけあります。
この中から簡単に使えるものを紹介したいと思います。
Selenium IDEのテストをJenkinsで実行
まずSelenium IDE。だいぶ古いものですが、なんだかんだ現場ではまだ使われています。このとき便利なのがSeleniumhqプラグインとseleniumhtmlreportプラグイン。
ダウンロード数でもこの2つはトップなので、やっぱりみんな使ってるんだなというのが分かります。
Seleniumhqプラグインですが、これが設定画面です。
Selenium IDEでテストスクリプトを自動記録したら、それをSubversionなどにいれて、あとはどのブラウザで実行したいか、どこのURLにアクセスするか、結果をどこに出力するかなどを設定。あとはJenkinsがやってくれます。
これを実行しますと、こういうレポートが出てきます。右側のグラフは繰り返しテストを実行した履歴です。青い部分がOKで赤い部分がNG。この記録がずっと残るので、テストの成功と失敗の傾向が分かるようになっています。
テストが多い場合はseleniumhtmlreportプラグインで見やすく表示することもできます。
Selenium WebDriverを使っている場合
Selenium WebDriverを使っている場合には、プラグインは不要です。その代わり、xUnit形式でテスト結果を生成すれば、それをJenkinsが読んでくれてテストレポートができる、ということになっています。
この方法では、Jenkinsでテスト実行をしたときに、いつからテストが失敗したのかが分かるという利点があります。
例えば1つ前のビルドはOKだったけれど今回のビルドからテストが失敗している、とか、3日前のビルドから失敗している、といったことが分かります。
並列でテストをしてくれるSelenium Gridとの組み合わせ
最後は応用編ですが、Seleniumには並列でテストを実行するSelenium Gridという仕組みがあります。これもJenkinsで利用するためのプラグインがあります。これもたくさんダウンロードされています。
Selenium Gridではマシンを複数台使っていて、1つのマシンがハブに、それ以外がノードになって、それぞれのノードで違うブラウザを用いてテストをしたり、テストケースを割り振ってテストすることができます。
このSelenium Gridでは、ハブやノードを指定する設定が面倒なので、もともとJenkinsにある複数のマシンでテストをする機能と組み合わせて、Jenkinsで設定をすれば周辺のマシンをSeleniumのノードにして実行できるようにします。
設定画面で、これはSelenium用というラベルを付けたマシンを使うという設定をして、そのマシンではFirefoxを3つ起動する、といった設定で簡単にGridができます。
JenkinsでSeleniumのテストをするときに気をつけること
最後に、JenkinsでSeleniumのテストをするときに気をつけることをまとめてみました。
なるべくほかのマニュアルのテストに邪魔されないように、専用のテスト環境を用意することや、たいてい毎日繰り返してテストを実行するのでデータを初期化する仕組みがあったほうがいいでしょう。
これは個人的な好みかも知れないのですが、ジョブはなるべく機能のカテゴリごとに分けて作るのがいいかなと思っています。なんでかというと、例えば1000個のテストがあるとして、たいていそのなかの1つか2つは毎日失敗するんですね。で、ずっと失敗が続いていると、みんなその失敗を見なくなります。
そこで機能ごとに、例えば1つのカテゴリにはテストが20個しかなくて、それが50個並んでいて、45個はOKだけど5個は失敗していますだと、みんな失敗をちゃんと見やすくなると思うので。
それから、Jenkinsでテストに失敗したときの解析がしやすいようにスクリーンショットをとる、というのがあって、これはちょうど昨年のアドベントカレンダーに「Seleniumでテスト失敗時のスクリーンショットを取得する方法」として書いたので、よければお読みください。
ご静聴ありがとうございました。
第1回 日本Seleniumユーザーコミュニティ勉強会
あわせて読みたい
サトヤ・ナデラ氏。マイクロソフト新CEOとして最初のインタビュー。46歳、まず社内でイノベーションの障害になるものを取り除いていく
≪前の記事
JavaScriptテスト自動化ツールSeleniumのこれまでとこれから(後編)。第1回 日本Seleniumユーザーコミュニティ勉強会