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

第13回フクオカRuby大賞 (2021) 本審査のプレゼン資料です。

ふりかえり記事はこちらです。
https://yusukeiwaki.hatenablog.com/entry/2021/01/24/puppeteer-ruby-on-fukuoka-ruby-award-13

Transcript

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