Vital pointofseleniumdesignpatternsandpractices

1. + 「Seleniumデザインパターン & ベストプラクティス」の勘所 2016/02/06 第3回Selenium勉強会株式会社SHIFT 太田健一郎 & 玉川紘子

2. + アジェンダ  どちらかというとアンチパターンなデザインパターン  テストコードを改善するデザインパターン  更なる改善のために  Seleniumデザインパターン & ベストプラクティス  自動テストウェアのアーキテクチャー  手動テストをそのまま自動化するとありがちなテストコード

3. + Selenium Design Patterns and Best Practices  残念なテストコードから始めて各種のデザインパターンとベストプラクティスを適用しながら品質の高いテストコードへと変えていく手法が見事です  書籍のコードはRubyですが、Web上にJavaリソースもあります  2015/09に太田&玉川監訳でオライリーさんから翻訳書として出版させて頂きました  Seleniumを使ったGUIテストのデザインパターンとベストプラクティスを解説した書籍です

4. + 自動テストウェアのアーキテクチャー http://www.infoq.com/articles/gui-automation-patterns より

5. + 手動テストをそのまま自動化するとありがちなテストコード  まずは問題のあるコードを見てみましょう  https://github.com/ootaken/Seleniu mBestPracticesBook

6. + どちらかというとアンチパターンなデザインパターン  Record and Playback パターン  Spaghetti パターン  Chain Linked パターン  Big Ball of Mud パターン

7. + Record and Playback パターン  利点  テストコードを素早く作成できます  プログラミングの経験が不要です  画面要素の検索が不要です  欠点  生成されるロケーターが分かりにくいです  テストコードの柔軟性がありません  テストデータが固定値で記録されます  生成されるテストコードが構造化されていません  生成されるコードが重複しています  概要  キャプチャ＆リプレイ・ツールを使って記録したスクリプトをそのまま利用するパターンです  再実行のための一部定数の変数化や実行前の置換は実施します

8. + Spaghetti パターン  利点  早くテスト自動化が始められます  テストコード自体が小さくなる可能性があります  スモークテストには向いているかもしれません  欠点  このデザインパターンは長期的なテスト自動化にはアンチパターンです  テストコード間の結合度が高すぎます  テストを並行実行できません  最初の方のテストで失敗するとテストスィート全体が失敗します  他のテストの失敗が別のテストの失敗に繋がります  概要  テスト自動化アーキテクチャと設計がありません。そのため、  テストコードが構造化されていません  テストケース依存関係がある場合があります  テストケースを個別に実行できない場合があります  Record and playback パターンを使って生成されたテストコードの多くがこのパターンで実装されています

9. + Chain Linked パターン  概要  Spaghetti パターンを改善し、テストコード自体はDRY テストパターンを始めとする各種のパターンで構造化したものです  ただし、依然としてテストケース間に依存関係があります  依存関係に伴うSpaghetti パターンが抱える欠点を引き継ぎます

10. + Big Ball of Mud パターン  概要  Spaghetti パターンにHermetic テストパターンを適用し、テストコード自体は独立しています  このため、個別実行、並行実行、ランダム実行は可能です  しかし、テストコード全体としては構造化されておらず、テスト自動化アーキテクチャが不在のため、以下の問題が発生します  部品となるテストコードやテストデータの変更によって、意図しないテストケースの失敗が発生します  共有部品が保守困難なGod Class 化する可能性があります

11. + テストコードを改善するデザインパターン  DRY テストパターン  Hermetic テストパターン  ランダム実行順序原則

12. + DRY テストパターン  利点  テストコードが部品で構築されるようになります  テストコードの重複が減ります  テストコードの修正が早くできるようになります  欠点  テストコードのプロジェクト構造が複雑になります  適切なIDEのサポートが必須です  DRYを維持し続けるのは大変です  メンバー全員にプログラミングスキルが必要です  概要  テストコードにおいてDon't Repeat Yourselfを実践するパターンです  必要なコードは一つの場所に正しくまとめます

13. + Hermetic テストパターン  利点  各テストケースはまっさらな状態で開始します  テストがまとめて失敗することがなくなります  テストコードが部品で構築されるようになります  テストのランダム実行が可能になります  テストの並行実行が可能になります  欠点  事前に設計と部品の開発が必要になります  テストの実行時間が増加します  テスト実行時のリソースの消費が増加します  概要  テストケース間の依存関係を廃するパターンです  直接管理ができない外部への依存関係を廃します

14. + ランダム実行順序原則  利点  テストケース間の暗黙的な依存関係を防ぎます  他のテストケースの結果が別のテストケースに影響を与えるのを防ぎます  テスティングフレームワークによっては標準で組み込まれています  欠点  テストコードに大量の修正が必要です  テストケースの失敗を追うのが困難です  チームのフラストレーションがたまる可能性が高いです  ランダム実行をサポートしていないテスティングフレームワークが多いです  概要  テストケースを常にランダムに実行します  パターンと言うよりは原則といえます

15. + 更なる改善のために  振る舞いをテストする  Write Once, Test Everywhere パターン  Page Object パターン  Test Tool Independence パターン  テストスイートを成長させる  テストスイートを書くための戦略  スモークテストスイート→新機能戦略→リグレッションスイート  データ駆動テスト  Default Values パターン  テストを安定させる  Action Wrapper パターン  Back Hole Proxy パターン

16. + ぜひ、お手元に一冊！

Vital pointofseleniumdesignpatternsandpractices

健一郎太田