1.
2013/11/21
株式会社 FLECT
小西俊司

2.

今さらだけどもうちょっとテストの仕方をなんとかしよう
(--

3.





とりあえずググれ
Firefox Plugin
ブラウザでの操作をSeleniumのスクリプトとして記録
してくれる
Play1のテストフレームワークで実行可能
http://www.seleniumhq.org/download/
◦ 色々と並んでいるがとりあえずはSelenium IDEだけダウン
ロードすればOK
※現在最新版のFirefoxにSelenium IDEをインストールすると
ボタンのアイコンが表示されず無地のボタンになるが動作に
は問題ない

4.


画面遷移が発生す
るごとにタイトル
チェックを自動的に
差し込むようにする
不要なケースで差し
込まれることもある
が後から足していく
よりも削除していく
方が楽

5.


Selenium IDEをレコーディング状態にして、普通にブ
ラウザを操作するだけ
「assertXXXX」をIDE上で追加することもできるがあと
からテキストエディタで追加する方が楽なので、ここで
はテストシナリオの実行に集中した方が良い

6.

作成したテストケースは「PLAY1APP_HOME/test」
以下に「xxxx.test.html」という名前で保存する
◦ Paly1はtestフォルダにある「xxxx.test.html」ファイルを自
動的にSeleniumテストと判定する
◦ 必要に応じてサブフォルダを作成しても良い

Play1でテストするのでテストスイートの保存は不要
◦ テストスイートとはテストケースの一覧をリストしただけの
HTML
◦ テストの実行自体もSelenium IDEから行う場合はあった方
が便利かも

7.


Playを「play test」コマンドで起動
「http://localhost:9000/@tests」にアクセス
祈れ！
コンテキストメニューで「新しいタブで開く」
とすると単体テスト画面を開ける

8.


画面下部に実際の画面が表示される
ステップ実行も可能

9.

ＩＤＥでも修正できるが単純にコマンドがHTMLのTableで
羅列されているだけなのでエディタでざくざく編集する

10.

Cookieを利用するアプリでは先頭で「deleteAllVisibleCookies」を
実行する
◦ ログイン状態もクリアされるので毎回ログインから実行




要所要所でalertXXXXなどの検証コマンドを差し込む
いつ変わるかわからないような文字列は正規表現で
◦ 正規表現を使う場合は先頭に「regex:」をつける
Ajaxのレスポンスを待つ場合は「waitForXXXX」を使用する
存在するはずの要素が見つからない場合は「waitForVisible」でそ
の要素が見つかるのを待つ
◦ ページ全部読む前に探し始めてる？
Seleniumのバグのような気もするけど。。。

対象要素の特定は簡潔に
◦ 自動記録では「//div[@id=‘wrap’]/div[2]/div/div[2]/…」のようになるこ
とも
◦ 要素の特定にはXpathやCSSセレクタが使えるので変更の可能性を考えて適
宜使い分ける(場合によってはHTMLを修正してidをふる)

11.






assertTextPresent: ページのどこかにこの文字列があ
るか
assertText: 指定の要素にこの文字列があるか
assertAlert: Javascriptのalertにこの文字列があるか
assertValue: Form要素の値の検証
assertElementPresent: 指定の要素が存在するか
多分全部のコマンドが「assert」「verify」「waitFor」の3種
類ある
◦ Assert: 検証に失敗したらそこでテストを中断
◦ Verify: 検証に失敗してもテストを続行。テスト結果はエラーになる
◦ WaitFor: 検証に成功するまで30秒待機。(Ajax用)

12.

テストの実行前にRDB用のFixtureを実行することができる

HTMLテーブルの代わりに#{selenium}タグでスクリプト形式
で書ける
◦ #{fixture/}タグをHTML内に差し込むだけ
◦ Salesforce用のFixtureを実行する拡張を組み込むことも多分できる
◦ これも標準のタグの枠組み内
◦ Selenium IDEと併用する場合は使いどころ無いかも

Cacheの値とMockで送信したEmailの受信者をSelenium変
数にストアできる
◦ PLAY_HOME/modules/testrunner以下の
- TestRunner.java
- user-extensions.js
を参照
◦ ここの仕組みが理解できればSeleniumからDBやSalesforceの値に
アクセスするなど、やりたい放題の拡張が組み込めるはず。(試したこ
とないけど)

13.

個別に短いテストを作るよりもある程度長いシナリオで作る方が
有効(な気がする)
◦ 新規登録 -> 検索画面で確認 -> 編集 -> 検索画面で確認 -> 削除
のような粒度
◦ 間にValidationエラーの検証をはさむとか

テストにも設計が必要

実はテストよりも値を少しずつ変えたテストデータを作成する時に
重宝した
TestRunnerのソースはかなり目からウロコ

◦ アクションを縦に並べて、その横に確認事項を書いた程度のもので十分
◦ Seleniumがどういう仕組みで動いているのかがわかるようになる
◦ Seleniumからサーバーサイドにしかない情報にアクセスしたいという要
件を抱えているエンジニアに対して一つの解を示している(と思う)
◦ 仕組み自体はPlayやJavaに依存するものではないのでどんなフレーム
ワークにも移植可能(なはず)