ブラウザ自動化ライブラリPlaywrightの紹介とRailsでの利用可能性 - 弥生開発者ブログ

ブラウザ自動化ライブラリPlaywrightの紹介とRailsでの利用可能性

この記事は弥生 Advent Calendar 2024 (シリーズ1) の11日目の記事です。

はじめに

はじめまして、弥生株式会社のMisocaチームエンジニアの粟津です。

今回は比較的新しいブラウザ自動化フレームワークであるPlaywrightについて、その利点とMisocaでの利用可能性を検討した結果を書こうと思います。

Misocaについて

Misocaは簡単に利用できる請求書発行サービスです。請求書だけでなく、納品書や見積書、領収書の発行もできます。
インボイス制度や、弥生株式会社のサービスであるスマート証憑管理と連携した電子帳簿保存法対応もしております。
ぜひ使ってみてください。

www.yayoi-kk.co.jp

Misocaとブラウザ自動化

MisocaはRuby on RailsとVue.jsを利用して開発していますが、その中で多くの種類の自動テストを実行しています。
それらの自動テストの中で、特にe2eテストとビジュアルリグレッションテストはブラウザ自動化を利用しています。
ビジュアルリグレッションテストとは、過去の状態の画面のスクリーンショットとの差分を比較して差分を検知するテストです。

zenn.dev

ちなみにe2eテストとビジュアルリグレッションテストの両方とも、テストフレームワークであるRSpecとRubyのブラウザ自動化ライブラリであるCapybara(driverはselenium)を利用しています。
(Railsユーザーにはお馴染みの構成です。)

RSpec: Behaviour Driven Development for Ruby

GitHub - teamcapybara/capybara: Acceptance test framework for web applications


また、ビジュアルリグレッションテストではスクリーンショットの取得までをRSpec/Capybaraで行い、
差分検知と結果画面の出力にはreg-suitを利用しています。

reg-viz.github.io

ブラウザ自動化のつらさ

ユーザーの操作をシミュレートできるブラウザ自動化はとても便利で、ソフトウェアの品質を担保してくれます。
しかしそのメリットの反面、開発生産性の低下につながるデメリットもあります。

それは次の2つの点です。

  • テストが多くなると負荷がかかったり、実行時間がかかる
  • flaky(不安定)なテストが不定期で失敗し、再実行をする必要がある

Misocaでは主にリリース前やプルリクエストのマージ時に各種テストがCI上で実行されますが、上記のような理由で時間がかかると
開発生産性が低下し、結果としてユーザーへの価値の提供が遅くなってしまいます。

開発を進めるごとにテストケースが増えて実行時間が長くなることは一定仕方のないことではありますが、それでもなんとかしたいという課題意識がありました。

Playwrightとは?

そこで目をつけたのがPlaywrightです。
PlaywrightはMicrosoft製のテストやスクレイピングのためのブラウザ自動化ライブラリです。

playwright.dev

公式ドキュメントを参考にとても簡単に試すことができます。
(自分はインストール含めて5分くらいでテストが実行できました!)

Installation | Playwright

Playwrightの特徴とSeleniumとの違い

ブラウザ自動化といえばSelenium、という人も多いのではないでしょうか。
先述のようにMisocaでもCapybaraのdriverとしてSeleniumを利用しています。

PlaywrightとSeleniumにはどのような違いがあるのでしょうか。
Playwrightの特徴をいくつか抜粋しながら紹介します。

複数ブラウザサポート

Playwrightはデフォルトで、主要ブラウザであるChromium/WebKit/Firefoxをサポートしています。
Seleniumでも上記ブラウザへ対応はしていますが、それぞれのブラウザごとに設定をする必要があります。

対して、Playwrightではデフォルトの状態で各ブラウザ全てに対するテストが実行できます。
公式ドキュメントのチュートリアルでも何もせずに全てのブラウザでのテストが実行されます。ぜひ試してみて下さい。

また、エミュレーションによるモバイルブラウザのサポートもされているようです。

flakyなテスト対策

ブラウザ自動化の辛い点としてあげた、flakyなテストですが、Playwrightではこちらの点も対応しています。
例えば、Javascriptが利用されたアプリケーションのテストをする際、特定の要素が出現するまでに時間がかかってテストが失敗することがあります。
このような場合、これまでは明示的に待ち時間を設定することで要素の表示を待つ方法を取ることが一般的です。

対して、Playwrightでは明示的な待ち時間を設定する必要がなく、自動的に要素の変更を待つことができます。
また、flakyなテストの再実行に関する機能もしっかりと用意されているので、特定のテストが落ちてしまったら全てのプロセスを再実行、といった無駄を省けます。
このような機能がデフォルトでサポートされているのが嬉しいですね。

playwright.dev

Playwrightの結果出力

個人的に一番魅力的だった点はこちらの機能です。
Playwrightではデフォルトで結果の出力ができます。
このようにブラウザごとの結果から、各テストケースごとの操作手順、どこで失敗したのかが非常に分かりやすく確認することができます。

playwright.dev

これまでのブラウザ自動化ではテストが失敗した際に原因を探すことも大変でしたが、Playwrightでは何か起きた時でデバッグしやすいことは大きなメリットです。

そもそもRailsに使えるの?

ここまでPlaywrightについて調べてみましたが、そもそもRailsに使えるのでしょうか?
答えは「YES」です。

実は、Misocaでも利用するCapybaraのdriverとしてPlaywrightを指定することができます。

playwright-ruby-client.vercel.app

driverを切り替えるだけなので、個別のテストケースの書き換えは必要ありません。

Misocaでも先行して、ビジュアルリグレッションテストのdriverを切り替えてみました。
しかし、Capybaraを少しカスタマイズして利用している箇所で調整を行う必要があり、残念ながらまだ移行はできていません。
(また移行が完了した際にはテックブログを書きます…!)

今後の展望

これまで紹介したように、Playwrightには大きな可能性を感じています。
より気軽かつ高速にe2eテストやビジュアルリグレッションテストが実行できるようになることで、開発生産性を維持しながらユーザーへの確かな価値提供を早めることができます。

また、今回紹介した機能以外にも、画面収録ができたり、実際のブラウザを操作しながらテストケースを書き起こしたりもできます。
Playwrightを使いこなして、弥生の品質保証とその生産性とさらに向上していきたいです。

社員募集

弥生では一緒に働く仲間を募集しています!

弥生で働くことに興味がありましたら、求人一覧をぜひご覧ください。

herp.careers