puppeteer-ruby: Ruby/Railsのためのブラウザオートメーションツール

puppeteer-ruby: Ruby/Railsのためのブラウザオートメーションツール Yusuke Iwaki ＠第13回フクオカRuby大賞本審査プレゼンテーション

概要: 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テストは意外と難しい！ 11 YusukIwaki / hogehoge でログインしたらログイン後におすすめ一覧が表示されること

E2Eテストは意外と難しい！人間が「正しい」と思う判断基準 ≠ ソフトウェアの判断基準くるくるが表示し終わるまで待とう。。長い・・・おすすめ一覧は出ていない。
不具合ですね？最大30秒待っておすすめ一覧が出たらOK。出なかったら不具合ですね。

E2Eテストは意外と難しい！人間が「正しい」と思う判断基準 ≠ ソフトウェアの判断基準くるくるが表示し終わるまで待とう。。長い・・・おすすめ一覧は出ていない。
不具合ですね？最大30秒待っておすすめ一覧が出たらOK。出なかったら不具合ですね。おすすめが出るまで最大30秒は待つくるくるが消えたらおすすめが出ると思っているおすすめが出ていないので即時にNG判定する「くるくるが消えるまで待て」と明示的にプログラムが必要

概要: Ruby/Railsのためのブラウザオートメーションツール 14 背景：Webサービスの開発現場において、 Ruby on Railsは現在も非常に広く使われている。少人数の開発現場では、継続的な品質担保のために、自動試験が行われている。（CI: 継続的インテグレーション）

課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。 → JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容・E2Eテストは、品質担保のために単体試験が少ない（= 技術的に負債を抱えた）システムほど重要である・E2Eテストは、ソフトウェアの選定をしっかりしないと人間が「正しい」と感じる判断基準をソフトウェアで再現させるのが難しい

② Ruby/Railsにおける自動試験の運用課題 17 ブラウザ自動操作で遊ぶことは簡単。自動試験の継続的な運用はとても大変。

Ruby/RailsでのE2Eテストの運用 18

Ruby/RailsでのE2Eテストの運用 19

Ruby/RailsでのE2Eテストの運用 20 ベースはSelenium WebDriver

RailsのSystemTestでありがちな問題 21

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において、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。 → JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容・Ruby/Railsで一般的に利用されているのはCapybara ・CapybaraはベースがSelenium WebDriverで、画面遷移やDOM変更検知に弱い。「100回に1回失敗する」Flaky test問題を起こしやすい。・Flakyテスト問題を解決しないまま、数千テストケースを運用すると、完走率が0に近くなる

③ 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の救世主？ Puppeteer 35 ・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の共存の選択肢 40 DOM変更検知のAPIが実装されていない！

RubyとPuppeteerの共存の選択肢 41 共存させる選択肢が無かった。必要なものを必要なところから作ることにした。

Puppeteerとpuppeteer-ruby 42 引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overview

Puppeteerとpuppeteer-ruby 43 引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overview

Puppeteerとpuppeteer-ruby 44 引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overview concurrent-ruby websocker-driver

Puppeteerとpuppeteer-ruby 45 引用：https://pptr.dev/#?product=Puppeteer&version=v5.5.0&show=api-overview concurrent-ruby websocker-driver Rubyで再実装

Puppeteerとpuppeteer-ruby なるべくJavaScriptのクラス・メソッド構成は踏襲。 46 (独自色を出しすぎると、puppeteer-ruby自体の学習コストとなってしまうため） JavaScript Ruby

不安定テストだけ「補強」する 47 画面遷移をする部分 waitForNavigationの処理を両端に入れ、画面遷移を確実に待って次に進むよう補強フォームが入力可能になるまで待たないといけない部分 waitForSelectorを直前に入れ、有効なフォームの出現を待って次に進むように補強
→ puppeteer-ruby = Capybara(Selenium)とPuppeteerの”共存”を可能にする選択肢

課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。 → JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。本日のプレゼンテーションで説明する内容・Flakyテスト問題を根本解決できるPuppeteer (公式にはJavaScript向け)を Rubyからも利用できるようにするためのソフトウェアを開発した。・既存のRuby/Railsのテストケースを JavaScriptへ「置換」しないとPuppeteerが利用できない状況は解消。既存のテストケースと「共存」をして、弱いところをPuppeteerでピンポイントに「補強」することが可能となった。・「テストケースの運用負荷は下げたいが、置換するほど工数はかけられない」という組織へ、有用な選択肢/移行パスを提供できた。

課題：Ruby/Railsにおいて、現存する自動操作ソフトは精度が低く、自動試験の運用負荷が非常に高い。 → JavaScriptで高精度の自動操作ライブラリをRubyに移植。自動試験の運用負荷を改善。

ありがとうございました

puppeteer-ruby: Ruby/Railsのためのブラウザオートメーションツール

puppeteer-ruby: Ruby/Railsのためのブラウザオートメーションツール

More Decks by Yusuke Iwaki

Featured

Transcript