2016/2/6 に開催された、第３回日本 Selenium ユーザーコミュニティ勉強会に参加してきました。
当日（座って聞けた部分については）メモを残したりしてたので、加筆＆整形して残しておこうと思います。
開会あいさつ TRIDENT 伊藤さん
- 今回は参加者が多い。最終的に、スタッフ除いて 100 人程度となった。
- 『Selenium 実践入門』発売記念も兼ねて開催。そのため、この本にまつわる話もたくさん。
- ユーザコミュニティとしては今 Slack が活発で、気軽に質問もできる雰囲気：日本 Selenium ユーザーコミュニティ
- 勉強会申し込み時のアンケートを見ると、利用言語としては Java が多いが、最近は Ruby 等他の言語も増えてきている
- 同じくアンケートの結果、Selenium の利用目的はテストが多い。少し Web スクレイピングも。
SHIFT 太田さん＆玉川さん 「Selenium デザインパターン＆ベストプラクティス」の勘所
書籍の特徴
- IDE で記録したいけてないコードから始めて改善していくような内容
自動テストウェアのアーキテクチャ
自動テストやるときって作らないといけないものがいろいろある
- UIMap とか
- ライブラリとか
これらがないと、保守・メンテが大変になる。
長期運用しやすいように考えよう。
いけてないテストスクリプトの例
EC サイトの商品コメント欄の仕様として「同じ内容のコメントは複数投稿できない」と定まっているのに、テストスクリプトが毎回同じ文字列をコメントに書くような作りになっている
→ １回動かしたら２回目以降失敗する
アンチパターン
record and playback パターン
操作記録してそのまま実行する。
始めるにははやいが、スクリプトがわかりにくい
Sphagetti パターン
テストケース間の依存があるパターン。あるケースの失敗が原因で以降が動かないなど。
ChainLinked パターン
多少構造化したものの、依存関係があるパターン
BigBallofMad パターン
独立性はあって順番関係なく実行はできるが、構造化してないパターン
よいパターン
DRY テストパターン
DRY = Don’t repeat yourself！
DRY を維持し続けるにはそれなりのスキルが必要となる。
Hermetic テストパターン
依存関係をなくしたパターン。
テスト間の依存関係を無くすためにデータ準備等の処理が入るので、テストの実行時間が長くなる場合も。
トレードオフで考えよう。
ランダム実行順序原則
テストケースをランダムな順序で実行する。
順序依存になっていないかがわかる。
太田さんデモ
実際の良いパターンといまいちなパターンを見比べながら、実行
TRIDENT 伊藤さん「Selenium 実践入門」で学ぶテスト自動化の世界
Selenium テスト自動化の世界
一昔前は・・・
- CI とかあんまりやってる人がいない
- SeleniumRC/IDE があまり安定してない
- 事例もツールベンダの Web ページにちょっとあるくらい
- 開発プロセスから分離された自動テスト
その後
- 2010, 2011 あたりから商用とオープンソースのトレンドが移り変わってきている
- CI がメジャーになった
- オープンソースの存在感が増した
- 国内ユーザ企業からの事例発信が増えた
- 開発プロセスと統合された自動テスト
本の立ち位置
Selenium だけの使い方にとどまらない内容
- コマンドの解説は Java
- 巻末チートシートに主要コマンド文法
初心者が読んで終わりではなく、ずっと手元におきたい１冊になるようにした。
本ならではのコンテンツで、API ドキュメント読んだだけではわからない部分が書かれている。たとえば
- ファイルダイアログ
- Basic 認証
- HTTP ヘッダ
など。
運用や事例の章もある。
Geb、FluentLenium などの便利ラッパの紹介。
第一章（テスト自動化とそのメリット）では基本的な内容が書かれているが、買った人が読むというよりは、買った人が上司や後輩に「とりあえずこれ読んどいて」的な使い方を想定しているため。
Yahoo 太田さん E2E テストフレームワークを使用したテスト自動化事例
どうやって使うフレームワークを決めたか
各チームによって言語がまちまちで要件いろいろ。
その中で
- Nightwatch.js
- Protractor
を候補に調査。
Nightwatch.js のよかったところ
スクリプトやログが見やすかった
Protractor のよかったところ
自動待機機能があり、明示的に待機を書かなくてよかったのでスクリプトがシンプルに。
E2E テストとは
利用者の視点に立ってサービスが正しく動いているかどうか確認する
環境構築
テスト時に専用環境が自動構築される。
PhantomJS
ヘッドレスブラウザとしてPhantomJSも使った。画面出さないけどスクショが取れる。
PhantomJSをはじめとするヘッドレスブラウザだけを使うなら正直Selenium使う必要ないと思う #seleniumjp
— Kunio Okita (@okitan) 2016, 2月 6
結局この PhantomJS はうまく行かなかったので、リアルブラウザ（Firefox とか）をヘッドレス化してつかうことにした。
Xvfb を使って。
DeNA 平田さん STF と Appium をもちいた Android アプリの自動テスト
Fastest device testing Smartphone Test Farm
検証用端末をブラウザから操作できて、ほぼリアルタイム。
STF を聞いたことあるひとー！
10 人くらい？ぽつぽつ
Appium 聞いたことあるひとー
40 人くらいが手を挙げた
Android アプリの自動テストでの課題
-
まず、何使う？
→ Google からいろいろ提供されだしているので、あまり迷うことはなくなってる
環境面倒
- 実行端末が環境に繋がれてないといけない
- 端末で実行されているかの判断がいる
- Jenkins マシンにスマホを繋がないといけなかったり
- どのテストをどのスマホでやるかを固定しないといけなかったり
そこで STF（smartphone test farm）
- リモートデバッグもできる
Android アプリの自動テストは STF ＋ Jenkins ＋ Appium ＋ Docker
小島さん Azure を使って手軽にブラウザテストをはじめよう
エクセルにエビデンスをコピペする簡単なお仕事・・・は辛いですよね
効率よくしたい、辛いと思って自動化を始めた
自動化で悩んだポイント
いわゆるあるある。
ただこれからやる人には参考になるはず。
PooSunny さん Geb に実践入門するために
Selenium 実践入門にも書いてあるGebについての紹介
Geb のメリット
普通に書くとこんなに長いところが、Geb を使うと・・・こんなにすっきり！
Geb のデメリット
環境構築まわりが大変
Monocrea 桑原さん エビデンス取るのも自動化したい！
テストエビデンスとるの嫌だよね！
→ 会場から大きな拍手
だからブラウザの自動テストツールつくりました、エビデンスを自動で取って HTML レポート出力してくれるよ！というお話。
サイボウズ 宮田さん Selenium アンチパターン
サイボウズの事例は Selenium 実践入門にも。
アンチパターン１：なんでも Selenium
とにかく Selenium でなんでも自動化だ！と始めたものの、開発者の気まぐれでテストケースが追加されたり、自動化されているテストされていないテストが整理されてなかったり・・・
そうこうしているうちにメンテ工数増大してばーん
解決策・・・
Selenium を避けることを考えよう。
- 静的解析
- 単体テスト
- API テスト
- 手動テスト
など、最適なものを選ぼう。あえて自動化しないのも選択肢。
アンチパターン２：手動テストのかわり
開発プロセスの手動テスト部分にそのまま Selenium での自動テストを追加
→ 最終的に破綻
工数削減だけが目的だとつらい
常に繰り返し実行すること、につきる。
放置するとメンテ工数が増えていって手がつけられなくなる。
アンチパターン３：クロスブラウザがんばりすぎ
解決策・・・
IE はアレですよね
→ 会場が同意
ブラウザを絞ろう。過去にブラウザ依存の不具合がどれだけ出ているかなどで判断しよう。
戸田さん 薄っすい話百八式
テストでダメだったときにショウ君（VoiceText）に「○○ さんのコミットでテストが失敗したみたいっす」って喋らせたりするなど。とにかく面白い話。