第3回 日本Seleniumユーザーコミュニティ勉強会に行ってきた
2016/02/06 第3回 日本Seleniumユーザーコミュニティ勉強会
昨年のテスト自動化カンファレンスに続き、テスト系のカンファレンスに行ってきました。
「Seleniumデザインパターン & ベストプラクティス」の勘所
「Selenium デザインパターン＆ベストプラクティス」からのお話。書籍はテスト自動化カンファレンスのじゃんけん大会で頂いたのに読めてない。早く読まなきゃ。(>_<)
- 自動テストのアーキテクチャ
- UI Mapのようなレイヤーを持たせることで、変更が入ってもテストコードを修正しないで済むような感じ
- レイヤー分け重要
Badパターン
- Record & Playback パターン
ツールで記録したまんまのパターン。 記録はラクだけど、言うまでもなく冗長だったりテストの再利用性が低い。
- Spaghettiパターン
テスト自動化アーキテクチャと設計がない
テスト同士に依存関係がある（先行テストのデータを後続が使うなど）
テストがこけたら別のテストも道連れでこけたり、順番を変えたり抜いたりするとテストが動かなくなる
- Chain Linkedパターン
SpaghettiパターンをDRYパターンなどで構造化したもの。
でも依存関係などは残る。
- 泥だんご(Big Ball of Mud)パターン
SpaghettiパターンにHermeticパターンを適用したもの
Goodパターン
- DRYテストパターン
文字通り、テストコードをDRYにしたパターン。重複は減るけど、維持が大変という面もある。IDEのサポート必須。
- Hermeticテストパターン（Hermetic=密封されている、秘伝のタレという意味）
テスト間の依存関係を排除するパターン。
各テストはまっさらな状態から開始する。
- ランダム実行順序原則
テストケースを常にランダムな順番に実行する
テストケース間の暗黙的な順序依存を防ぐ
テストコードの失敗が追いにくい、修正が大量に発生するなど弊害も多い
「Selenium実践入門」で学ぶテスト自動化の世界
Geb
Groovy+Gradle+Geb
FluentLenium
Capybara
Rubyのラッパーライブラリ
E2Eテストフレームワークを使用したテスト自動化事例
どっちを使うか検討した
①Nightwath.js（結果的にこっちを採用。Reactを使う予定だからprotractorは落選）
Node.jsベース
Selenium Serverの制御が可能
CIサポート
（利点）
テストスクリプトやテストログが見易い
②protractor
AngularJSアプリケーションに特化
Node.jsベース
自動待機（WaitForAngular）API
Angularのレンダリングと$httpの呼び出しが完了するまで自動で待機する
ダイレクトブラウザーアクセス
ページオブジェクトパターン
- 操作と検証を分離するパターン
ヘッドレスブラウザー = 画面がでないブラウザ
Phantom.jsではダウンロードのテストがうまくいかなかったりで断念。
- リアルブラウザのヘッドレス化を検討
- xvfbでヘッドレス化
STFとAppiumをもちいたAndroidアプリの自動テスト
STFがオープンソース化したのをきっかけに採用。現状はこれ一択。 検証端末をブラウザから操作できる。反応もほぼリアルタイム。
Azureを使って手軽にブラウザテストをはじめよう
初心者と言うことでしたが、最終的にAzureでテストを動かすまでに至った話。
Gebに実践入門するために
Groobyでブラウザ操作の自動化できるGebの話。 Geb使うなら、Intellij IDEA！
エビデンス取るのも自動化したい！
エビデンスにスクショ撮るの辛いよね、そこで 操作した画面要素を赤く囲われるスクショが撮れるすごいツールSiToolkit PCブラウザだけでなく、スマホのブラウザやアプリでも使えるとのこと。
https://github.com/sitoolkit/sit-wt-all/wiki
Seleniumアンチパターン
私の大好きなアンチパターン系の話。自分で痛い目に会ってみることも時には必要とは思うけどないに越した事はない。フグに当たった人がいるから今フグが食べれるのです！
KintoneチームのSeleniumテスト
- 1000以上のテストケース。
- すべてのテストが年間で1000回以上実行
- 年間数10件単位のバグを防いでいる
でも、社内には導入に失敗した例も沢山ある。
- 運用してみたけど続かない
- コストの割にはメリットがない など
アンチパターン１ なんでもSeleniumでやろうとする
- 無計画になると何が自動化されていて、何がされてないか分からなくなる。
- 数が増えてメンテナンス不能に
改善策
頻繁に確認したいE2Eのテストをシンプル、メンテできる範囲でSeleniumを使うように。結果、受け入れ試験だけに絞った。
アンチパターン２ 手動テストの代わりに使う
UIの変更でテストが動かなくなり、一旦テストを止めるとさらにソースと乖離してメンテ不能に。 自動テストツールを導入するときには、テストコードを常にメンテするような開発プロセスも見直しが必要。開発プロセスを変えるには推進役が必要。 Selenium以前に、Unitテスト、CI/CDを布教してメリットをみんなに実感してもらうと良いかも。
改善策
- テストをこけさせた人は修正を義務化。常にコードとテストが一致できる状態に。
アンチパターン３ クロスブラウザ頑張りすぎ
欲張って実行しても毎日何かしらの問題が起きてメンテで死ねる。特にIEが不安定できつい！ SeleniumのEdge対応はまだ。 ヘッドレスブラウザのPhantomJSはファイルアップロードに問題があり諦めた。
改善策
ブラウザをChromeに絞った。自分たちの過去のブラウザ依存の重要不具合を分析したが、Seleniumで防げるものがほぼなかったため。OSもLinuxにしてDockerで管理し、安定とメンテが楽に。
どうしてもクロスブラウザでテストしたければsauceLABSなどのTaasも検討してみては？
薄っすい話百八式
Selenium実践入門に仕込んだ隠しネタの話やVoiceTextでXFDのフィードバック音声作った話。独特の語り口で面白い話でした。
まとめ
Seleniumの事は知らないことばかりなので、ためになる話ばかりでした。
Selenim実践入門買おう。でも自分は積読になっているオライリーのSelenium本２冊を片付けなければ。
