2016年2月6日、東京ミッドタウンのヤフー株式会社にて、日本Seleniumユーザーコミュニティ主催による「第3回日本Seleniumユーザーコミュニティ勉強会」が開催されました。今回は、2015年9月発行の『Seleniumデザインパターン&ベストプラクティス』で監訳を務められた玉川紘子氏・太田健一郎氏、2016年2月に発売された『Selenium実践入門』の著者である伊藤望氏・戸田広氏・宮田淳平氏を筆頭に、Seleniumを使って最先端で活躍しているエンジニア9名が登壇し、熱い思いや事例を参加者と共有しました。
ごあいさつ（伊藤望氏）
日本Seleniumユーザーコミュニティの主宰者である伊藤望氏による開会のあいさつがありました。勉強会をはじめとするコミュニティの活動が活発であり、人数も拡大しているというお話に続き、勉強会申込者アンケートの結果が発表されました。
伊藤望氏
アンケート結果
- Q：Selenium/Appiumでご利用のプログラミング言語をお聞かせください（複数回答可）
- A：結果としては、やはりJavaとSelenium IDE強しといったところです。しかしながら第1回と比べて使用者の人数が約2倍に増えたRubyなどもあり、さまざまな言語で利用され始めている状況がうかがえました。
- Q：Selenium/Appiumの用途をお聞かせください（複数回答可）
- A：システムの部分テスト・全体のテストに利用する方が大勢を占めていますが、データ入力などの定型操作や技術的趣味で扱っているという方も少なくないようでした。
第3回日本seleniumユーザーコミュニティ勉強会
『Seleniumデザインパターン&ベストプラクティス』の勘所（玉川紘子氏・太田健一郎氏）
2015年9月に発行された同書の監訳者である玉川紘子氏、太田健一郎氏からは、同書の手法とデザインパターンについての話がありました。
玉川紘子氏
太田健一郎氏
『Seleniumデザインパターン&ベストプラクティス』の紹介
本書は2015年9月に出版されました。仮のECサイトで商品レビューを行うという動作をテーマにしており、最初は残念なテストコードから始めて、デザインパターンを適用しながら品質の高いコードに直していくという手法を取っています。開発者ではないメンバーでも順々にきれいなテストコードを学べるようになっており、割と初心者向けかなと思います。書籍のコードはRubyですが、WebからJavaのサンプルコードもダウンロードできます。
どちらかというとアンチパターンなデザインパターン
どちらかというとアンチパターンになるデザインパターンとして以下が挙げられます。
- Record and Playbackパターン
- Spaghettiパターン
- Chain-Linkedパターン
- Big Ball of Mudパターン
まずは動かすことを第一にし、こういったアンチパターンによって作っていてもとりあえず動くようになったテストスクリプトは、その後にリファクタリングしてきれいにしていく必要があります。
テストコードを改善するデザインパターン
一方、テストコードを改善するデザインパターンとしては以下が挙げられます。
- DRY（Don't Repeat Yourself）テストパターン
- Hermeticテストパターン
- ランダム実行順序原則
デザインパターンを適用する
本書に掲載されている残念なコードについて改めて見ていくと、以下のような問題点が見えてきます。
- 順番に実行しなければならない（依存性）
- 重複している
リファクタリングの考え方として、コードが重複しているところはメソッドとして切り分けていくべきです。また、原則的にはDRYテストパターンとHermeticテストパターンを適用して、依存性を絶ったり構造化していくのが良いでしょう。
更なる改善のために
ここまでは本書の基本的なところですが、さらに考え方を進めていくことができます。
- 振る舞いをテストする
- Page Objectパターン
- データ駆動テスト
- テストを安定させる
- テストスイートを成長させる
最後に
この時間では語り尽くせないほど、Seleniumの自動化は奥が深いです。さまざまなプラクティスがありますので、『Seleniumデザインパターン&ベストプラクティス』をぜひ一度手に取ってみてください。
「Seleniumデザインパターン & ベストプラクティス」の勘所
『Selenium実践入門』で学ぶテスト自動化の世界（伊藤望氏）
「ずっと手元に置きたい1冊」「幅広いトピックを網羅」という方針で書かれた『Selenium実践入門』を著者の立場から紹介していただきました。
Seleniumテスト自動化の世界
ひと昔前と最近の比較
2008年ごろ、CI（Continuous Integration、継続的インテグレーション）ツールの利用はまだまだ少なく、リリースサイクルを早くするという認識が広まっていない状況でした。また当時は商用ツールの存在感が大きく、Selenium RC/IDEでは安定運用が難しい状況でした。自動テストが開発プロセスからも分離されているのが普通でした。
最近ではSeleniumのシェアが商用ツールを上回りました。CIツールがメジャーになり、リリースサイクルを短くしなきゃいけないよねと言う人も増えてきました。Selenium WebDriverになってかなり安定してきて、ユーザー企業の事例発信も多くなってきました。開発者が使うようなエディタでテストコードを書いてCIツールで実行・確認するなど、開発プロセスと密接に関わってくるのが主流になるかと思います。
『Selenium実践入門』の立ち位置
そういった中で本書は、WebDriverを使ってエンジニアがプログラムを書いて自動化するというところを主眼に置いています。また、Selenium単体ではなく、さまざまなツールと組み合わせて使うというのが一般的になっているので、ツールの利活用や運用、事例など、実践的な内容は取り入れていこうという形になっています。
『Selenium実践入門』ってどんな本？
読者が初心者を脱した後でもずっと手元に置きたい1冊になるようにとこだわって執筆しました。また、Seleniumと一緒に使うツールも増えていて、それらもSeleniumの体系の一部だろうと位置づけて幅広いトピックを網羅しています。
ずっと手元に置きたい1冊
本書では、たとえば公式なWikiやAPIドキュメントを見てもよくわからないノウハウをフォローしています。また、ややこしいマイナー機能も挙動を調べてできるだけ解説しました。また、うろ覚え文法にはチートシートだろうということで、自分でもすぐ出てこなくて調べたくなるような文法を巻末の一覧にまとめました。
そして、実運用に役立つコンテンツということで、運用時に気をつけること（第13章）や、現場での役割分担や課題をまとめた事例（第14章・第15章）も掲載しました。
幅広いトピックを網羅
Geb、FluentLenium、Capybaraといった最近メジャーとなってきたライブラリについてもページ数を割いて解説しています。モバイルでは実機とエミュレータでのテストをしています。CIツールとの連携として、Jenkinsの設定やSelenium Grid＋Jenkinsの分散実行というトピックもあります。
『Selenium実践入門』各章ピックアップ
続いて、『Selenium実践入門』の各章をピックアップします。時間の関係上、全部の章をご紹介することはできませんが、今回ご紹介できない章についても、ぜひ本書を手にとってご覧くださればと思います。
第1章「テスト自動化とそのメリット」
意外と類書には載っていない話題です。テスト技術者でない方にも読んでいただき、テスト自動化のメリットや必要性の理解につなげてくださればという思いで書きました。
第4章「WebDriverコマンド徹底解説」
文字通り徹底解説ということで、ブラウザの生成や要素の取得、ポップアップの操作といったWebDriverの各コマンドを使い方を丁寧に解説しました。本書で一番ボリュームのある章です。
第5章「WebDriverコマンドの実践的活用」
ファイルのアップロードやダウンロードを始めとした、実際に現場で遭遇するであろうさまざまな課題に対して、普段はあまり使わないWebDriverコマンドや周辺ツールを使って解決する方法を説明しています。
第7章「Geb」
Javaの開発者が、テストくらいはGroovyとかGradleとか使いたいというケースを想定して、セットアップからGroovyの文法まで解説しています。Gebを扱った本は世界初かと思いましたが、洋書で他にも数冊ありました。
第8章「FluentLenium」
割とGebに近いテスティングフレームワークですが、こちらは比較的マイナーだと思います。さすがにFluentLeniumを扱った本は世界初だろうと思っていましたが、やはり他にもありました。
第9章「Capybara」
Rubyのラッパーライブラリですが、厳密にはラッパーではなく、内部のライブラリはSelenium以外のものに差し替えることができます。このCapybaraについても解説をしています。
第12章「CI環境での利用」
Jenkinsを利用したジョブのセットアップや、マスタ・スレーブ環境の構築などを解説しています。最近はTravis CIやCircleCIが使われるケースも多いですが、そのあたりは私のブログで扱っています。
第14章「サイボウズの事例」
開発プロセスにおける各段階でのテスト活動やQAと開発の役割分担、また本格運用時の課題など、よくまとめられています。
第15章「DeNAの事例」
自動化をメインで取り組むチームの事例で、こちらはブラウザテストやネイティブアプリのテストを扱っています。いろいろな工夫が出ていますので、読み応えがあります。
最後に
『Selenium実践入門』が、みなさんの手元にずっと置きたい1冊になれば幸いです。
「Selenium実践入門」で学ぶテスト自動化の世界
E2Eテストフレームワークを使用したテスト自動化事例（太田邦昭氏）
今まさに取り組んでいるという、NightWatchJSでテスト自動化を行う事例が紹介されました。リアルブラウザのヘッドレス化という手法も話題となり、聞き応えのあるセッションとなりました。
太田邦昭氏
テスト対象サイト
今回、テスト自動化を実行した対象サイトは以下のようなものでした。
- JavaフレームワークとしてAngularJSを使用
- 外部とのデータのやりとりはスタブで代用
- テスト実行時に専用環境が自動構築される仕掛け
テストフレームワークを決める
まず、以下に挙げる各チームの開発言語や要望を考慮して、テストフレームワークを検討していきました。
- JavaScriptのテストが行えること
- 簡単にスクリプトの作成と実行ができること
- JavaScriptベースでスクリプトが書けること
- Jenkinsとの連携ができること
- ヘッドレスブラウザとの連携ができること
検討の結果、これらの要件に対応できそうなテストフレームワークとして以下の2つが候補となりました。
NightWatchJS
NightWatchJSは以下のような特徴があります。
- JavaScriptベース
- シンプルにスクリプトが書ける
- Selenium Serverの制御ができる
- CIをサポート
- 拡張が容易
Protractor
Protractorは以下のような特徴があります。
- AngularJSに特化
- JavaScriptベース
- WaitForAngular()
→待機処理を明示的に指定しなくてもレンダリングを待機する
- ダイレクトブラウザドライバ接続
ヘッドレスブラウザ
テストフレームワークよりも先にヘッドレスブラウザに何を使うか決めておかなければなりませんが、今回は以下の理由からPhantomJSを選択しました。
- ヘッドレスブラウザとしてメジャー
- JavaScriptのテストを走らせるためによく採用されている
- NightWatchJSとProtractorでサポートされている
- 技術情報が豊富
- WebKitベース
- スクリーンショットが取れる
- jQueryでページを操作できる
- 自動パフォーマンス解析ができる
NightWatchJSとProtractorで検討しましたが、利用するフレームワークを変更するなどの理由があり、今後のシステムとの親和性がより高いNightWatchJSを選択しました。
テストを書く
今回自動化したかったのは、アカウントに関するテスト、表示に関するテストと、CSVのダウンロードに関するテストです。実際にテストを書くうえでのポイントは以下の通りです。
- CSS Selectorで柔軟に要素を特定
- ページオブジェクトパターンの適用で保守性を向上
→UI操作系のコードと検証系のコードを分離
- ダウンロードのテストはカスタムコマンド・カスタムアサーションで対応
リアルブラウザのヘッドレス化
テストを実行してみると、PhantomJSでは挙動が不安定だったり固有の問題があり、ダウンロードも失敗しました。本質的でないところで工数がかかるため、別の手法を探すことにしました。結果としまして、リアルブラウザではテストが成功していますので、Xvfb（X virtual framebuffer：UNIX/Linuxで、仮想ディスプレイによる画面の入出力をエミュレートできるツール）を使ってヘッドレス化し、テストも正常に実施できました。
また、マルチブラウザでテストをしたいということだったので、Selenium Gridを使って、IEやSafariのテストは実行しています。
Jenkinsとの連携
Jenkinsとの連携では、以下のような流れでテストが実行されるようにしました。
- Jenkinsからテスト対象のWebサイトを自動構築
- Jenkinsがテスト実行するコマンドを投げる
- 上記で作った各ブラウザが並列でテスト実行
- テスト結果の可視化
環境ができたということで、本格的に動き出すのはこれからですが、取組中の案件の事例として紹介しました。
Q&A
- Q：JavaとJavaScriptを使える要員の数に差がない場合は、どちらを選ぶべきか、優先度などあるでしょうか。
- A：今回の事例では、社内的にはJavaを書くとなった場合拒絶反応が出てしまうので、仕方なくJavaScriptを使っています。そうした制限が無いのでしたら、Javaベースのテストフレームワークを選択されたほうが良いと思います。
- Q：成熟したフレームワークがJavaの方が多いからでしょうか。
- A：そうですね。やはり1から自分たちでテストフレームワークを作るのは大変なことです。今オープンソースで出ているフレームワークのほうが、機能も豊富ですし、事例も見つけやすいので良いと思います。
- Q：運用で一番大変なことは何でしょうか。
- A：今はほぼ自動で動いていますので、バージョンアップの影響などで何か起きたときに調べるくらいです。
- Q：IEでのテストもしているということですが、Windows Serverを立てるのは大変ではないでしょうか。
- A：実は、Windows Serverではなく、Windowsクライアントを使っています。以前Windows Serverを使っていたところ、権限の問題があって動かなかったことがあったからです。Windowsクライアントで十分動作します。
SeleniumE2Eテストフレームワークを使用したテスト自動化事例
STFとAppiumをもちいたAndroidアプリの自動テスト（平田敏之氏）
「やや緊張しています」と言いながらも、とても滑らかに、時に笑いを取りながら発表していた平田氏は、デモが多く盛り込まれたセッションを披露してくださいました。
平田敏之氏
Androidアプリの自動テストにおける課題
Androidアプリを自動でテストするにあたり、以下のような課題が挙げられます。
- 自動テストに何を使うか？
- 自動テストを実行する環境のよくある制約
『Selenium実践入門』p.365～366にも同様のことを書いていますが、執筆後にこれらの課題が解決しましたので、発表させていただきます。
Androidアプリの自動テスト
まず、Appiumが本当に使えるかどうかをお見せするために、今回は世に出ているアプリであるMERYを使って、実際にAppiumのテストケースを書いてみました。一切動くかどうかわからない状態でコードを書いていますが、結果は成功でした。このようにAppiumは世に出ているアプリにも使えます。
自動テストの実行環境
Appiumが動作することはわかりましたが、いざ実行してみると以下のような環境の制約が出てきます。
- 自動テストを手元で動かすと結構つらい
- つらいのでJenkinsで動かすようにする
- Jenkinsに端末を接続しなくてはならない
- 端末がたくさん無いので誰かが使っているときは使えない
- 自動テストを実行する端末が固定化される
STF（Smartphone Test Farm）
私たちは、こうしたAndroid端末管理の課題を解決するために、株式会社サイバーエージェントが開発したSTF（Smartphone Test Farm）というデバイスファームを使うことにしました。
STFはスマートフォンの端末別のテストをブラウザから実行できるようにし、リモートデバッグも可能でつながっていない端末の操作ができるなど、とても便利なツールです。
一方で欠点としては、ブラウザからしか動かせないという点があります。ですので、我々はAPIを開発・追加してJenkinsから動かせるようにしました。STF 2.0.0から適用されています。
STF2.0.0の新機能
STF2.0.0は、以下のようなことが可能です。
- 端末のstatus（利用中 / オンライン etc.）が取得/変更可能
- 端末の情報（OS / Model etc）が取得可能
複数台のスマートフォンが接続されて、それぞれほとんどディレイせずにブラウザから動作させることができたり、IPを指定して別のPCに接続されたスマートフォンを認識したりと、かなり使えるツールに仕上がっています。
最後に
『Selenium実践入門』の原稿を出してから数ヵ月が経過し、ここまで進化しましたという発表でした。ぜひ、STF@2.0.0のAPIを利用してみてください。また、さらに簡単に使えるように、現在STF用のJenkins Pluginも開発中です。
Q&A
- Q：STFを選んだ理由は何でしょうか。
- A：自分たちでもこうしたデバイスファームを作ることを検討していたのですが、STFが発表され、実際に試してみたらよかったからです。
STFとAppiumをもちいたAndroidアプリの自動テスト
Azureを使って手軽にブラウザテストをはじめよう（小島直也氏）
小島直也氏からは、ブラウザテストの自動化を進めるにあたって直面した問題と解決策が発表されました。
小島直也氏
はじめに
テストを実行し、画面のスクリーンショットをコピー＆ペーストして証跡を残す手作業は、どうしてもモチベーションが下がってしまいます。しかし、自動化をすれば、定期的に実行するだけでよく、証跡も自動でレポートされるので、生産性が上がります。
テストの自動化に取り組んだ理由
私たちは以下の理由からテストの自動化に取り組むことにしました。
- 同一のマニュアルテストを繰り返すのは非効率だと感じていた
- デプロイの頻度が高い時期には終わったばかりのテストを繰り返すこともあった
- 自動化スキルがあれば効率化できると考えた
ブラウザテストの自動化のはじめ方
まずは動くテストスクリプトを書くところから始めました。しかし、作法がわからないので、以下のサイトなどを参考にしました。
ToolsQA
ToolsQAはチュートリアル形式でテストの自動化を解説してくれている英語のサイトで、とても参考になります。
Stack Overflow
Stack Overflowは困っているときに相談すると、詳しい人が解説してくれているサイトで、こちらも英語で書かれています。大体の問題はここで解決します。
日本Seleniumユーザー会の談話会やSlack
Slack上で行われる日本Seleniumユーザーコミュニティの談話会などにも積極的に参加し、実際に現場で使っているエンジニアの方とセッションするのもとても有益でした。
自動化で直面した課題と解決策
自動化を進めるにあたり、以下のような課題に直面しました。
- 遷移先のポップアップ画面IDを取得できない
- テスト対象の画面が表示される前にテストが進んでしまう
- スクショを撮るコードをテスト毎に書いてしまったので大変だった
- ロケータをIDで指定していたら同じページで同じIDが出てきて困った
- 1つのテストケースを1クラスに実装するべきか悩んだ
- データ駆動でアプリの機能を実行するように実装するべきか悩んだ
- データ駆動でアプリの機能を更に詳細に実行するように実装するか
- 前のテストの失敗によって次のテストが実行されない
- 結合テストはスパゲッティテストにあたるか
- 開発言語に何を選択するか
- テスト実行中はブラウザに画面を専有されてしまう
特に最後の問題が本題になります。この問題を解決するために、自分のPCを使用していないときに流してみましたが、テストが失敗していて翌日やり直すことになりました。そこで、Azure VMでテストを実行してみることにしました。
実践的な自動テストに仕上げるためにやったこと
自分のテストフレームワークを作りました。
- テストデータの読み込み処理
→TestNGのDataProvider機能を使い、テストデータを読み込む処理をテストと分離しました。
- 任意のブラウザでのテスト実行
→プロパティファイルで実行ブラウザを切り替えられるようにしました。
- Web Elementが表示されるまでのテストの待機処理
- スクリーンショット取得処理
- ロガー
この結果、テストを追加するときに手を加える個所を、以下の3ヵ所に限定しました。
- Page Object
- アプリケーション機能定義部
- アプリケーション機能実装部
Azureで作ったSelenium Grid
UbuntuをSeleniumのハブ、Windows Server 2008をノードとして、IEを動かすという仕組みをAzureで作りました。
Selenium談話会やSlackでたくさんの方に色々と教えていただいてきました。誠にありがとうございました。本日の話が一助となれば幸いです。
Azureを使って手軽にブラウザテストの自動化をはじめよう
Gebに実践入門するために（PoohSunny氏）
『Selenium実践入門』にもレビュアーとして携わっていたPoohSunny氏からは、今話題のGebについてのセッションがありました。
PoohSunny氏
Gebについて
Gebは最近有名になってきたGroovy製のSeleniumラッパーです。普通に書くと長くなってしまうコードも簡潔にできるのが特徴です。前回の勉強会で玉川紘子さんが発表されたスライドが非常に良いのでぜひご一読をおすすめします。
脱・独自改造！ GebでWebDriverをもっとシンプルに
こういう資料を見てよさそうだと思って導入しようとしても、いくつかつまずきポイントがあります。今日はそのポイントと対処法をご説明します。
環境を構築して動かすまでが遠い
Gebでドキュメントを見てみると、だいたいGradleを使っている例が多いです。GradleはGroovyの動的言語っぽさが濃く、Groovyをやったことのない人にとっては習得コストが高いです。
解決策として、Gebの公式サンプルを使うと良いです。すぐ動きますので、このサンプルに継ぎ足していって動作を見ていくのが良いのではないでしょうか。Gradle版のほか、Maven版とCucumber JVM版もあります。
また、試しに使うときはテストとプロジェクションでプロジェクトを分けるのがいいかもしれません。以前JavaのコードをGroovyコンパイラでコンパイルしたらうまくいかなかったことがありますので、Geb用のプロジェクトを立ててあげることをおすすめします。
表記が独特で戸惑う
Groovyの力でオブジェクトの隠蔽が行われているので、表記が独特です。最初は訳がわからないと思います。
解決策としては、IDEにサポートしてもらうならば、型を明示して挙げると補完が利きます。IntelliJ IDEAだとより賢くて、補完機能が優秀になっています。IntelliJ IDEAをお使いの方にはGebを強くお勧めします。Gebにはお勧めポイントがたくさんあるのですが、たとえば、テストに応じて自動でキャプチャを取得してくれるGebReportingSpecという機能もあり、なかなか便利です。
どう書いたらいいか迷う
Gebはさまざまな書き方ができるため、どう書いたらいいかわからなくなってしまうことがあります。また、ドキュメントも英語ということで若干敷居が高いです。
解決策としては、以下のような方法があります。
エビデンス取るのも自動化したい！（桑原雄一氏）
Webアプリのエビデンスとして代表的なものにスクリーンショットがあります。Seleniumの機能を使っても取得できますが、取得したい個所にコードを書く必要があり、ソースの可読性が落ちる ―― 桑原雄一氏のセッションでは、そんなSeleniumerの悩みを解消するオープンソースのツールSI-Toolkitが紹介されました。
桑原雄一氏
エビデンスを手動で取るのが嫌だと感じる理由
エビデンスを手動で取ることをエンジニアが嫌がる理由として、以下が挙げられます。
- スキルが身につかない
- テストを疑われている感じがする
- その時間で打鍵したほうが品質が上がるんじゃないか
今回はそんなエンジニアを助けるためのツールをご紹介します。
SI-Toolkitで自動取得できるエビデンス
SI-Toolkitを使うと、以下ののエビデンスが自動取得できます。
- 操作ログ
- 操作要素の位置とサイズ
- スクリーンショット
これらのエビデンスをSI-Toolkitがどのように取得しているかをご説明します。
動作の仕組み
まず、スクリーンショットにエビデンスとして見せるために必要な情報を紐付けてあげます。それから、プログラムで画面操作しているときにスクリーンショットに紐付けたい情報をまとめておきます。あとはスクリーンショットに枠線などを書き出してあげます。こういう処理をすることで、エビデンスが見やすい状態になっています。
最後に
SI-Toolkitに関しまして勉強会を開いたりもしていますので、興味のある方はふるってご参加ください。
Q&A
- Q：スクリーンショットを取得する機能は複数のブラウザで対応していますか
- A：対応しています。
- Q：Appiumを経由すればモバイルでも対応できますか
- A：Appiumにも対応していますので、モバイルのネイティブアプリもハイブリッドアプリもエビデンスが取れます。
Seleniumアンチパターン（宮田淳平氏）
Seleniumを使って自動化すれば万事解決 ーー そんなよくある考え方に待ったをかけるのが、『Selenium実践入門』著者のひとりである宮田淳平氏。Selenium導入後に問題が起こる事例について、豊富な経験から語っていただきました。
宮田淳平氏
Seleniumのよくある課題
Seleniumの導入失敗事例の主なものとして、以下のような問題があります。
- 運用してみたけど続かない
- コストの割にはメリットを感じない
- 改善したいけどよくわからない
こうしたよくある落とし穴と対策がもっと広まるとよさそうだと思い、発表します。今回はアンチパターンを扱います。
アンチパターンの定義
アンチパターンは以下のように定義されています。
- 最初は有益だと思えるが、最終的に悪い結果をもたらすもの
- リファクタリングするための方法が存在する
アンチパターン1 なんでもSelenium
不具合の再発防止をしたい、手動で試験したくない、常に保証したい何かがあるといったときに、Seleniumですべて解決できるように思えます。
問題点 —— Seleniumは大きい
Seleniumには「大きい」という問題があります。
- メンテナンスコストが大きい
- 簡単なテストでも数十秒から数分と、実行時間が長くかかってしまいます。また、ネットワークやテスト対象が不安定になりやすいです。
粒度が大きい
- 1メソッド・1リクエストで確認できる挙動のためにブラウザまで動かすのはやりすぎなところがあります。
考え方
Selenium以外の選択肢も検討してみるのも重要ではないかと思います。
適切な選択をするためには、Seleniumの長所と短所を理解することが必要ではないでしょうか。
長所
長所は以下の通りです。
- E2Eレベルでの保証ができる
- 人間ではほぼ不可能な速度とタイミングで実行ができる
短所
短所は以下の通りです。
まとめると
頻繁に確認したいE2Eレベルのシンプルなテストを、メンテナンスできる範囲の数であればSeleniumでの自動テストを活用しましょう。
アンチパターン2 手動テストの代わり
既存の開発プロセスにSeleniumテストを取り入れたいというパターンで、これもよくあります。手動テストで行われているテストの一部をそのままSeleniumに肩代わりさせようとする考え方です。
問題点 —— 自動化したテストが通らなくなり、手が付けられなくなる
回帰試験をSeleniumテストで自動化したところ、実装期間のUI変更でSeleniumテストが通らなくなりました。乖離が大きすぎるのでいったん放置して手動でテストを行っていましたが、最終的にはメンテナンス不能になりました。
手動テストの代わりだけだとSeleniumテストのメリットを最大化できないのではないかと思います。工数削減だけではなく、自動テストならではの速度とタイミングでテストができることに注目するべきでしょう。
また、もう一つの問題として、Seleniumテストを放置するとソフトウェア本体との乖離が大きくなり、メンテナンスコストが膨らむ一方になります。
改善の方向性
自動テストのメリットを最大化するために、開発プロセス自体を考え直す必要があると思います。理想的には本体が変更されるたびにテストが実行されることです。そうすることで乖離が最小になります。少なくとも可能な範囲でテストの頻度を上げていくことが大切だと思います。
ただ、開発プロセスを考え直すのは大変です。推進役を立てて進める必要がありますが、どうしても難しい場合は、まずは単体テストとかから導入していって、メリットが実感できれば社内の協力者を増やしていけるのではないでしょうか。
まとめると
Seleniumテストを手動テストの置き換えに留めずに、常に繰り返し実行される開発プロセスを目指しましょう。開発プロセスを変えていくための推進役を立て、少しずつメリットを実感していきましょう。
弊社では、デプロイパイプラインを構築して、コード変更のたびにSeleniumテストをすべて実行するようにしました。誰が落としたかもわかるので、落とした人が即修正するよう義務化しました。こうすることで常に製品とテストとの乖離が無い状態を保て、問題の早期発見にもつながり、安心感も出てきます。
アンチパターン3 クロスブラウザがんばりすぎ
動作環境のすべてのブラウザで品質保証したいがために、Seleniumテストをすべてのブラウザで実行しようとするアンチパターンです。
問題点 —— すべてのテストが通ることはなく、メンテナンス不能に陥る
IE8〜IE11、Firefox、Chromeで毎日すべてのSeleniumテストを実行していたところ、必ず失敗するテストがありました。原因調査と環境のメンテナンスに多大な時間がかかり、最終的にメンテナンス不能になりました。
考え方
Seleniumテストをクロスブラウザで運用するのは思ったより大変です。ブラウザのバージョンとWebDriverのバージョンがあり、それらの組み合わせ数が増えるにつれてトラブルに直面する可能性が高くなります。特にIEは不安定なブラウザです。
改善の方向性
ブラウザを絞るしかないと思います。ブラウザ依存の重大な不具合が過去にほとんど無いならば、FirefoxやChromeが安定していると思います。IEのサポートも、古いバージョンは終了し始めています。
Microsoft Edgeは、WebDriver対応状況が公開されていますが、重要な機能がサポートされていないということで、まだ早いかなと思います。
ヘッドレスブラウザは、以前PhantomJSではファイルアップロードが動かなくて諦めたのと、Seleniumでの運用事例をあまり見かけないという辛さがあります。
どうしてもクロスブラウザでSeleniumテスト実行したい
Taas（Tool as a Service） Platformの活用を検討するのがいいと思います。Sauce Labsのようなブラウザ環境を貸してくれるようなところを使えば、メンテナンスコストは解決できるのかなと思います。
まとめると
ブラウザは可能な限り絞りましょう。絞れないならばTaaSを検討しましょう。社内では過去のブラウザ依存の不具合を集計したところ、重要な不具合でSeleniumで発見できる種類のものはほぼありませんでしたので、Chromeのみに絞りました。動作も安定し、メンテナンスも楽になりました。
最後に
アンチパターンの兆候としては、テスト自動化のメリットが感じられず、必要以上に苦労していると感じられることが挙げられます。Seleniumは便利ですが落とし穴もありますので、あらかじめアンチパターンを知って回避しましょう。
Selenium Antipatterns
薄っすい話百八式（戸田広氏）
『Selenium実践入門』に掲載されている小ネタのお話、音声合成のお話、Selenium Gridを用いてインターネット越しにノードを構築したお話が披露されました。
戸田広氏
『Selenium実践入門』校正をくぐり抜けて出版された小ネタ
『Selenium実践入門』はかなり細かいレベルの校閲が入りました。しかし、その目をくぐり抜けて出版された小ネタがあります。第12章289ページに、ポート番号として4126番を指定されています。これは某有名ホテルの電話番号から持ってきました。
結論
ユーモアを大事にしましょう。ハードな仕事でもね。
俺と音声合成
第13章319ページに、CIの結果通知の例として「Eメール」「RSS」「チャットツールへの自動投稿」と並んで、「音声」が挙げてあります。人間の耳は人間の声に注意が向くよう最適化されています。このことを利用して、自動テスト時のエラー通知を音声合成にしてみるのはいかがでしょうか。
音声合成ソフト
代表的な音声合成ソフトには、以下のようなものがあります。
今回は某人気旅番組のナレーターにも使用されているVoiceTextのSHOW君にSeleniumのエラー通知をさせてみましょう（筆者注：本当に残念ながら、本レポートではお伝えしきれませんが、予想の斜め上を行く音声合成のおもしろさに、会場は大盛り上がりでした）。
結論
ユーモアを大事にしましょう。ハードな仕事でもね。
俺とSelenium Gridハブがインターネットで特殊ノード
プロキシを立ててポート番号を80番にしよう
Selenium Gridでは、RemoteWebDriverからSeleniumServerへの通信は4444/tcpなどの独自ポートが使われています。これをプロキシ立てて80番にしたら動くのかなと思って実装してみたところ、動きました。
インターネットに公開できないか
次に、こうしたWell-knownポートなWebサービスはインターネットに公開してもいいんじゃないかという気がしてきます。実験してみたところ、これも構成は変わっていないので、動きます。
HTTPSで接続するように変えることはできないか
じゃあ、HTTPをHTTPSに変えることはできるのかなということを検討してみました。私が調べたかぎり、これはできないようです。ノードに指定できるハブへの接続プロトコルが、現状でHTTP限定のようです。
ノードを自分の家に置いて運用できるか
これが本題になります。たとえばノードにMacを接続したいときなど、自分の家にある実機に接続できないかと考えたりします。これは、結論から言うと一応可能です。ルータでNAT変換する必要があり、ノードの設定も変更する個所が出てきますが、動きます。悩みどころとしては、ハブとノードの通信が双方向であるために、ハブからノードに通信するための穴を家のルータに空けなければならないという点が挙げられます。これは少し不安です。
結論
Seleniumは閉じたLAN環境で実行しましょう。
Seleniumの薄っすい話 百八式
以上、参加者数・セッション数とも過去最大のボリュームで行われた「第3回日本Seleniumユーザーコミュニティ勉強会」の紹介でした。最新の事例を始めとして全9セッションが展開された、非常に濃い内容の勉強会となりました。残念ながら今回のレポートでは詳しくは触れられませんでしたが、全体的にデモが多く、Web画面やアプリがサクサクと動作する様子が披露されると、会場からはどよめきも起こっていました。
翻訳本の『Seleniumデザインパターン&ベストプラクティス』に加え、決定版とも呼べる出来の『Selenium実践入門』が発売されたことにより、日本語の情報がますます手に入りやすくなっているSelenium。利用者の裾野が広がっている熱いテスト自動化ツールです。勉強会に参加された方の中には、これから使ってみようと考えている方も多くいらっしゃいました。テスト自動化に取り組まれる方にはぜひ一度、国内に強力なコミュニティを擁するSelenium/Appiumに触れてみていただければ幸いです。
