Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単になって捗った

Omotesando.rb #91 (https://omotesandorb.connpass.com/event/299381/) で発表した資料です。

1. Tomoya Chiba (@tomoasleep) Rails のブラウザテストを Playwright で動かすよう にしたらデバッグが簡単になって捗った 1
2. 千葉 知也 (@tomoasleep) Qiita 株式会社 エンジニア SNS (?) https://twitter.com/nemunemu3desu https://qiita.com/tomoasleep 今日は Kaigi Effect をうけて(?) LT しにきました 自己紹介 2
3. アンケートします 3
4. Rails のブラウザテスト (System Spec, Feature Spec, ...) 書いてる人 4
5. 一部のページで導入 壊れると非常に困るページ ( 登録フロー、ログイン、記事ページ、エディタ, ...etc) フロントエンドが複雑な箇所 ( 年々複雑になってきているので、もうちょっとテスト増やしたい…) ブラウザテストには Feature Spec を使用 Qiita におけるブラウザテスト 5
6. 独特の記法 (Capybara の DSL) に慣れない 時々よくわからない理由で落ちる 落ちたときのデバッグが難しい Rails ブラウザテストでの課題 6
7. テストを書けるメンバーを増やしにくい 独特の記法 (Capybara の DSL) に慣れない 書いたテストをメンテナンスしていく上で困る 時々落ちる 落ちたときのデバッグが難しい Rails ブラウザテストでの課題 ( 分類 ) 7
8. テストを書けるメンバーを増やしにくい 独特の記法 (Capybara の DSL) に慣れない 書いたテストをメンテナンスしていく上で困る 時々落ちる 落ちたときのデバッグが難しい Rails ブラウザテストでの課題 ( 分類 ) 8
9. いわゆる Flaky Test がブラウザテストで多い 色々な理由で落ちることがある wait する時間が短すぎる 不安定なテストデータ その他 困ること (1): 時々落ちる 9
10. 単にテスト結果を見るだけだと、原因が把握しにくい 特に CI で落ちたときに難しい 場合によっては、ローカルで再現出来ないことがある ただ不安定ならまだ良いが ( 良くないが) 違うと 地獄のデバッグ が始まる ことになる… 困ること (2): デバッグが難しい 10
11. Rails ブラウザテストは課題が山積み 11
12. つ https://playwright.dev/ Microsoft 製のブラウザテストツール つらみを解決しているツールはないか？ 12
13. Playwright は Trace viewer でテストの状況をリプレイすることが可能 (Cypress なども近い機能はある) Playwright の Trace Viewer が便利 13
14. Console log も見れる Playwright の Trace Viewer が便利 14
15. Network Request も見れる (Request, Response ももちろん見れる) Playwright の Trace Viewer が便利 15
16. Ruby 用クライアントが開発されている playwright-ruby-client capybara-playwright-driver # こんな感じで書ける page.goto("/tests/#{user.id}") page.wait_for_selector('input').type('hoge') page.keyboard.press('Enter') expect(page.text_content('#content')).to include('hoge') Playwright を Rails で動かす 16
17. capybara-playwright-driver を使えば、コードはほぼそのまま に導入可能 Capybara Driver でコードほぼそのままで導入可能 17
18. RSpec.describe "Todos", type: :system do before do driven_by(:playwright) end # ... end Rails 7.1 で capybara-playwright-driver を使う設定が System Test に組み込まれ た Add support for Playwright as a driver for system tests by yuki24 · Pull Request #48950 · rails/rails Rails 7.1 で System Test に設定が組み込まれた 18
19. 2~3 日程度の作業で移行完了 一部挙動が違う部分を書き換えた程度で、ほぼそのまま移行できた Playwright を導入 19
20. 落ちたテストの Trace を自動で保存するように設定した 設定方法は Rails のブラウザテストを Playwright で動かすようにしたらデバ ッグが簡単になって捗った #Ruby - Qiita 落ちたテストの Trace を自動保存するようにした 20
21. CI で落ちたテストの状況を手元で確認できるようになった ※ Action などが一部分かりにくい部分がある (Capybara 経由のため) CI で落ちたテストのデバッグが容易になった 21
22. 落ちたテストのデバッグが容易になった テストの落ちる頻度が体感減った(?) ( が、色んな改善を同時にやっていたので、Playwright だけの効果かは不明) → 少ない工数でブラウザテストのつらい部分を改善できた 移行の効果 22
23. テストを書けるメンバーを増やしにくい 独特の記法 (Capybara の DSL) に慣れない → 未解消 書いたテストをメンテナンスしていく上で困る 時々落ちる → 解消 (?) 落ちたときのデバッグが難しい → 解消 元々の課題に立ち返る 23
24. 将来的には Node.js ベースへの移行もあり？ 24
25. 将来的には Node.js ベースへの移行もあり？ 25
26. 将来的には Node.js ベースへの移行もあり？ 26
27. Kaigi on Rails で 「Playwright で Rails 資産を使いつつ JS でブラウザテストす る」手法が紹介されていた https://kaigionrails.org/2023/talks/YusukeIwaki/ https://speakerdeck.com/yusukeiwaki/kaigionrails2023pub Node.js ベースだと、いろいろメリットがある 公式ドキュメント (https://playwright.dev/) を参考文献として使える VSCode 拡張 (https://playwright.dev/docs/getting-started-vscode) の恩恵を 受けられる 画面を触りながらテスト生成、テスト実行、デバッグなど、 将来的には Node.js ベースへの移行もあり？ 27
28. 俺たちの Kaigi Effect はこれからだ (?) 28
29. https://qiita.com/advent-calendar/2023 CM (1): Advent Calendar 2023 オープン 29
30. 社員みんなでもりもり書いていきます https://qiita.com/advent-calendar/2023/qiita-inc CM (1'): Qiita 社 Advent Calendar もやります 30
31. オンラインLT イベントで、登壇者と参加者募集中です！！ Qiita のエンジニアも話します 詳しくは https://increments.connpass.com/event/297116/ CM (2): Qiita 主催の LT イベントがあります 31
32. Qiita に書いた記事 Rails のブラウザテストを Playwright で動かすようにしたらデバッグが簡単に なって捗った #Ruby - Qiita (https://qiita.com/tomoasleep/items/71b792cb2f89235db1ca) サンプル実装: https://github.com/tomoasleep/rails-sample-with-playwright playwright-ruby-client 作者の解説記事 https://yusukeiwaki.hatenablog.com/entry/2021/05/18/capybara- playwright-driver E2E testing on Rails https://speakerdeck.com/yusukeiwaki/kaigionrails2023pub Further Reading 32