Rails のブラウザテストをデバッグしやすくするための Playwright 導入
Qiita株式会社 / tomoasleep
メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|
11名〜50名 | 2023年10月 | B to C |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
Qiita では重要な機能の動作を検証するために、Rails の ブラウザテスト (Feature Spec / System Spec) を利用し、 そのテストの実行環境として Selenium を利用しています。 「バックエンドとフロントエンドを一気通貫で見れる」などのブラウザテストの利点はある一方で、「テスト自体のデバッグが難しく、特に一見関係ない変更で CI が落ちたときの対処が難しい」という課題がありました。 スクリーンショットを保存するなど、ツールを変えない範囲で様々試してはいたものの、あまり改善につながっていない状態でした。 また、ブラウザテストは普段のテストでも書かない DSL が多く散見され、なかなか書ける人が増えない、書くにしても書き方を調べるのが難しい、という問題がありました。
どのような状態を目指していたか
他のメンバーが実行した CI 上のテストであっても、デバッグに必要な情報を得られる状態を目指していました。 また、 MUST ではないのですが、 機能や情報が豊富で書きやすい JS 系のブラウザテストツールへの移行の足がかりになれば、ということを意識していました。
比較検討したサービス
- Cypress (cypress-rails, cypress-on-rails)
比較した軸
- デバッグに利用できる機能 (リアルタイムではなく、 CI で落ちたテストをあとから調査するのがやりやすいとなお良い)
- 導入のための変更コスト (元々のテストコードに対して、どのような変更が必要になるか)
- ツール自体の開発の活発さや普及度合い
選定理由
Cypress でも Playwright でもデバッグ用の機能はあるのですが、決め手になったポイントは「既存のテストを大きく変えることなく動作できる」点です。
Cypress を rails で動かすツール (cypress-rails, cypress-on-rails) は、テストの大きな変更が必要がありますが、 Playwright では、 capybara-playwright-driver により、既存のテストを変えずに移行が行えるため、移行が容易でした。
実際に一部のテストの移行を試し、既存のテストにほぼ手を加えずに移植できるため、 Playwright を導入するツールとして選ぶことにしました。
導入の成果
改善したかった課題はどれくらい解決されたか
Playwright 導入後は、期待通りデバッグがかなり行いやすくなりました。
以前は、Feature Spec が CI で失敗しているという相談があったときに、手元で再現する状況を作る必要があるなど、調査にかなり手間がかかっていました。 しかし、Playwright 導入後は CI にアップロードされている Trace を TraceViewer で確認することで、必要な調査がほとんど行えるようになりました。
導入時の苦労・悩み
意外にも導入で苦労した点はあまりなかったです。
トラブル発生も想定して、事前に周知していたのですが、導入後に大きなトラブル等はありませんでした。
導入に向けた社内への説明
上長・チームへの説明
Playwright 自体は OSS で利用自体は無料のため、検討した内容としてはツール導入の工数のみでした。 capybara-playwright-driver を利用することで既存のテストにほぼ手を加えずに、多少の環境構築で利用可能になるので、導入は割に合うと判断しました。
導入前には、 社内のエンジニアに対して、こうした技術選定の背景、ツールの概要などの説明を行いました。 設定を完了し導入するタイミングでは、不具合を発見した場合の対応方法、どうやって Trace Viewer を利用するかなどの、利用方法や問題への対応方法を共有を行い、いざというときは自分を巻き込むことでなんとかなる体制を作ってから導入を行いました。
活用方法
よく使う機能
Trace viewer: 導入の大きな目玉になった機能で、テスト中の画面の内容を時系列毎に追えたり、 Console や Network 通信の情報も確認できるなど、ブラウザテスト版デバッガとして利用できます。
ツールの良い点
capybara-playwright-driver により、 Rails アプリケーションへの導入は容易な部分です。 また、開発が活発なツールで、 Trace Viewer や各種拡張などの周辺ツールも豊富です。
ツールの課題点
Rails と組み合わせる事例がまだ多くはない点です。
基本的な利用は問題はないのですが、ある程度複雑なことを行うのに深い調査が必要になったり、JS 版のコードやドキュメントを脳内補完して理解する部分が必要になったり、チームで開発するためのコード規約やベストプラクティスを考える必要が出てきます。
ツールを検討されている方へ
Playwright が Rails の System Test でサポートされるツール になったことも踏まえて、 Rails でブラウザテストを利用するなら、基本 Playwright で良いと思います。
今後の展望
Playwright によってデバッグは行いやすくなりましたが、ブラウザテストを書くこと自体の難しさ、 (Capybara という中間層を利用しているために) Trace がやや難解だったりするなど、ブラウザテスト周りの取っ付きにくさはまだ一定あるかなと感じます。
こうした難しさは、 Ruby で書いているブラウザテストを JS に移植することで、 VSCode 拡張 の恩恵を受けられたりなど、改善していけるのではと考えています。
Qiita株式会社 / tomoasleep
メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名
よく見られているレビュー
Qiita株式会社 / tomoasleep
メンバー / バックエンドエンジニア / 従業員規模: 11名〜50名 / エンジニア組織: 11名〜50名