第13回フクオカRuby大賞 (2021) 本審査のプレゼン資料です。
ふりかえり記事はこちらです。 https://yusukeiwaki.hatenablog.com/entry/2021/01/24/puppeteer-ruby-on-fukuoka-ruby-award-13
puppeteer-ruby: Ruby/RailsのためのブラウザオートメーションツールYusuke Iwaki＠第13回フクオカRuby大賞 本審査プレゼンテーション
View Slide
概要: Ruby/Railsのためのブラウザオートメーションツール2背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。多くの開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。
概要: Ruby/Railsのためのブラウザオートメーションツール3背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。多くの開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容
① 「自動試験」4継続的に品質を担保するために
自動試験 = 単体テスト + E2Eテスト5単体テスト：クラス/モジュールが設計通りの動作をすることを確かめるE2Eテスト: ブラウザ自動操作により、機能の正当性を確かめるYusukIwaki / hogehogeでログインしたらログイン後におすすめ一覧が表示されること
E2Eテストは負債を抱えたシステムほど重要https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid理想：単体テストが充実していて、E2Eテスト/人力試験はオマケ程度現実的には、単体試験が少なく、E2Eテストでカバーしないといけないケースも多い。
E2Eテストのベース技術：ブラウザ自動操作7あたかも人間が操作しているかのようにブラウザを「自動操作」すること機械的に刺激を与える
E2Eテストのベース技術：ブラウザ自動操作8機械的な刺激を与える方法は２種類あるWebDriver Protocol CDP（Chrome DevTools Protocol）・10年以上の歴史があり、対応ブラウザが多い・対応言語も非常に多い・対応ブラウザはChromeと一部のFirefoxのみ・公式な対応言語はJavaScriptのみ
E2Eテストのベース技術：ブラウザ自動操作9機械的な刺激を与える方法は２種類あるWebDriver Protocol CDP（Chrome DevTools Protocol）・10年以上の歴史があり、対応ブラウザが多い・対応言語も非常に多い・対応ブラウザはChromeと一部のFirefoxのみ・公式な対応言語はJavaScriptのみどんな環境でも「なんとなく」は 自動操作できる一部の環境のみだが、かなり高精度に自動操作できる。
自動試験 = 単体テスト + E2Eテスト10単体テスト：クラス/モジュールが設計通りの動作をすることを確かめるE2Eテスト: ブラウザ自動操作により、機能の正当性を確かめるYusukIwaki / hogehogeでログインしたらログイン後におすすめ一覧が表示されること
E2Eテストは意外と難しい！11YusukIwaki / hogehogeでログインしたらログイン後におすすめ一覧が表示されること
E2Eテストは意外と難しい！人間が「正しい」と思う判断基準 ≠ ソフトウェアの判断基準くるくるが表示し終わるまで待とう。。長い・・・おすすめ一覧は出ていない。不具合ですね？最大30秒待っておすすめ一覧が出たらOK。出なかったら不具合ですね。
E2Eテストは意外と難しい！人間が「正しい」と思う判断基準 ≠ ソフトウェアの判断基準くるくるが表示し終わるまで待とう。。長い・・・おすすめ一覧は出ていない。不具合ですね？最大30秒待っておすすめ一覧が出たらOK。出なかったら不具合ですね。おすすめが出るまで最大30秒は待つくるくる が消えたらおすすめが出ると思っているおすすめが出ていないので即時にNG判定する「くるくるが消えるまで待て」と明示的にプログラムが必要
概要: Ruby/Railsのためのブラウザオートメーションツール14背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容
概要: Ruby/Railsのためのブラウザオートメーションツール15背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容・E2Eテストは、品質担保のために単体試験が少ない（= 技術的に負債を抱えた）システムほど重要である・E2Eテストは、ソフトウェアの選定をしっかりしないと人間が「正しい」と感じる判断基準をソフトウェアで再現させるのが難しい
概要: Ruby/Railsのためのブラウザオートメーションツール16背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容
② Ruby/Railsにおける自動試験の運用課題17ブラウザ自動操作で遊ぶことは簡単。自動試験の継続的な運用はとても大変。
Ruby/RailsでのE2Eテストの運用18
Ruby/RailsでのE2Eテストの運用19
Ruby/RailsでのE2Eテストの運用20ベースはSeleniumWebDriver
RailsのSystemTestでありがちな問題21
RailsのSystemTestでありがちな問題22
RailsのSystemTestでありがちな問題23
RailsのSystemTestでありがちな問題24
RailsのSystemTestでありがちな問題Flaky test: 正しいのに、なぜかNGになる問題25
Flaky test: 正しいのに、なぜかたまに失敗する問題● Capybaraは、ときどき、なぜかDOM要素を掴んでくれない○ 特に「画面遷移」「DOM変更検知」が弱い画面遷移 ・・・次のページが表示されるまで待つDOM変更検知・・・○○が現れるまで/消えるまで待つ○ リトライ処理を書くことで、問題発生率を減らすことはできる。が・・・大変26
Flaky test：「100回に1回だけ失敗する」はOK?● Flakyテストの単体成功率は99%27
Flaky test：「100回に1回だけ失敗する」はOK?● Flakyテストの単体成功率は99%○ テスト項目が1000程度で、Flakyテストが全体の2%程度（20項目）テストの完走率は 81.7% （5回に1度は 失敗する）○ テスト項目が8000あり、Flaky testが全体の1%(80項目)ある場合のテストの完走率は 44.8% (2回に1度は 失敗する)● 現実問題では、完走率はもっと０に近く、手動でのテスト結果精査作業が発生する / 手動テストで補完することが多い。28
概要: Ruby/Railsのためのブラウザオートメーションツール29背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容
概要: Ruby/Railsのためのブラウザオートメーションツール30背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容・Ruby/Railsで一般的に利用されているのはCapybara・CapybaraはベースがSelenium WebDriverで、画面遷移やDOM変更検知に弱い。「100回に1回失敗する」Flaky test問題を起こしやすい。・Flakyテスト問題を解決しないまま、数千テストケースを運用すると、完走率が0に近くなる
概要: Ruby/Railsのためのブラウザオートメーションツール31背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容
③ puppeteer-rubyによる自動試験の運用改善32求めたのは、既存テストケースと新しいテストケースの共存
【再掲】ブラウザ自動操作33機械的な刺激を与える方法は２種類あるWebDriver Protocol CDP（Chrome DevTools Protocol）・10年以上の歴史があり、対応ブラウザが多い・対応言語も非常に多い・対応ブラウザはChromeと一部のFirefoxのみ・公式な対応言語はJavaScriptのみどんな環境でも「なんとなく」は 自動操作できる一部の環境のみだが、かなり高精度に自動操作できる。Capybaraで使えるのはこっちだけ
【再掲】ブラウザ自動操作34機械的な刺激を与える方法は２種類あるWebDriver Protocol CDP（Chrome DevTools Protocol）・10年以上の歴史があり、対応ブラウザが多い・対応言語も非常に多い・対応ブラウザはChromeと一部のFirefoxのみ・公式な対応言語はJavaScriptのみどんな環境でも「なんとなく」は 自動操作できる一部の環境のみだが、かなり高精度に自動操作できる。Rubyでもこっちを使ってみたいよ？？
Flaky testの救世主？ Puppeteer35・Google Chromeチームが開発した、CDPを使う自動操作ツール・ブラウザの内部的な状態や、DOMツリーの変化を直接監視するため、「画面遷移」や「DOM変更検知」を完全に漏れなく行える。
Puppeteerの精度“JavaScript＋Puppeteerに移行ができたら” テスト精度が劇的に上がる36とても不安定で、11テストケースの完走率が０単純置き換えでも11テストケースの完走率が約50%まで改善
Puppeteerの精度“JavaScript＋Puppeteerに移行ができたら” テスト精度が劇的に上がる37とても不安定で、11テストケースの完走率が０単純置き換えでも11テストケースの完走率が約50%まで改善「移行」「置き換え」が必要！
Puppeteerの精度“JavaScript＋Puppeteerに移行ができたら” テスト精度が劇的に上がる38とても不安定で、11テストケースの完走率が０単純置き換えでも11テストケースの完走率が約50%まで改善「移行」「置き換え」が必要！「共存」させる選択肢が欲しい！
RubyとPuppeteerの共存の選択肢39
RubyとPuppeteerの共存の選択肢40DOM変更検知のAPIが実装されていない！
RubyとPuppeteerの共存の選択肢41共存させる選択肢が無かった。必要なものを必要なところから作ることにした。
Puppeteerとpuppeteer-ruby42引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overview
Puppeteerとpuppeteer-ruby43引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overview
Puppeteerとpuppeteer-ruby44引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overviewconcurrent-rubywebsocker-driver
Puppeteerとpuppeteer-ruby45引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overviewconcurrent-rubywebsocker-driverRubyで再実装
Puppeteerとpuppeteer-rubyなるべくJavaScriptのクラス・メソッド構成は踏襲。46(独自色を出しすぎると、puppeteer-ruby自体の学習コストとなってしまうため）JavaScript Ruby
不安定テストだけ「補強」する47画面遷移をする部分waitForNavigationの処理を両端に入れ、画面遷移を確実に待って次に進むよう補強フォームが入力可能になるまで待たないといけない部分waitForSelectorを直前に入れ、有効なフォームの出現を待って次に進むように補強→ puppeteer-ruby = Capybara(Selenium)とPuppeteerの”共存”を可能にする選択肢
概要: Ruby/Railsのためのブラウザオートメーションツール48背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容・Flakyテスト問題を根本解決できるPuppeteer (公式にはJavaScript向け)をRubyからも利用できるようにするためのソフトウェアを開発した。・既存のRuby/RailsのテストケースをJavaScriptへ「置換」しないとPuppeteerが利用できない状況は解消。既存のテストケースと「共存」をして、弱いところをPuppeteerでピンポイントに「補強」することが可能となった。・「テストケースの運用負荷は下げたいが、置換するほど工数はかけられない」という組織へ、有用な選択肢/移行パスを提供できた。
概要: Ruby/Railsのためのブラウザオートメーションツール49背景：Webサービスの開発現場において、Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。→ JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。
ありがとうございました
yusukeiwaki
holman
deanohume
erikaheidi
colly
hursman
revolveconf
philhawksworth
jlugia
davidbonilla
thoeni
michaelherold
sonatard