Rails のブラウザテストをデバッグしやすくするための Playwright 導入

ツール導入前の課題

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 が Rails の System Test でサポートされるツール になったことも踏まえて、 Rails でブラウザテストを利用するなら、基本 Playwright で良いと思います。

Playwright によってデバッグは行いやすくなりましたが、ブラウザテストを書くこと自体の難しさ、 (Capybara という中間層を利用しているために) Trace がやや難解だったりするなど、ブラウザテスト周りの取っ付きにくさはまだ一定あるかなと感じます。

こうした難しさは、 Ruby で書いているブラウザテストを JS に移植することで、 VSCode 拡張 の恩恵を受けられたりなど、改善していけるのではと考えています。