Chrome拡張機能のE2Eテスト、PlaywrightとPuppeteerどっちを選ぶ？調べて比較してみた

1. はじめに

こんにちは！iimonでフロントエンドエンジニアをしている「奥島」です！

Chrome拡張機能のE2Eテスト自動化を調べていると、ツール選定で必ず出てくるのが PlaywrightとPuppeteer の2択が多い印象です。

「Playwright or Puppeteer(パペティア)」の比較記事は世の中にたくさんありますが、一般的なWebアプリのテストを前提にしたものが多い印象です。Chrome拡張機能のテストに絞って比較している情報はあまり見かけない気がします。

そこで今回は、この2つをChrome拡張のE2Eテストという観点から比較してみたいと思います。

2. PlaywrightとPuppeteer(パペティア)の関係性

Puppeteer(パペティア)

開発元: Google（Chrome DevToolsチーム）
2017年リリース
特徴:
- 対応ブラウザ: Chrome / Chromium / Firefox / Edge
- 対応言語: JavaScript / TypeScript のみ

Playwright

開発元: Microsoft
2020年リリース
特徴:
- 対応ブラウザ: Chromium / Firefox
- 対応言語: JavaScript / TypeScript / Python / C# / Java

どちらもツール自体は複数ブラウザに対応していますが、Chrome拡張機能はChromium系ブラウザでしか動かないため、拡張のテストはChromium上で実行するみたいです。

3. Chrome拡張のテスト観点での技術比較

Chrome拡張のE2Eテストで重要になるポイントを表にまとめました。

やりたいこと	Playwright	Puppeteer	差
テスト用のブラウザに拡張機能をインストールする	できる	できる	なし
画面を表示せずにテストを実行する（CI/CD向け）	できる	できる	なし
Service Worker（裏側で常に動くバックグラウンド処理）にアクセスして、拡張のIDや内部の状態を確認する	専用APIがありシンプルに書ける	できるが書き方がやや複雑	Playwrightが楽
コンテンツスクリプト（Webページの中に入り込んで動く部分）が追加したボタンなどが表示されるのを待って操作する	自動で待機してくれる	自分で待機の指示を書く必要がある	Playwrightが楽
拡張のアイコンをクリックすると出るポップアップ画面をテストする	できる	できる	なし
テストの実行・結果表示・リトライなどを管理する（テストランナー）	最初から入っている	自分で別のツールを用意する必要がある	Playwrightが楽

基本的な仕組みは同じなので、どちらでもChrome拡張のテストはできます。

大きな違いが出るのは以下の2点です。

コンテンツスクリプトの自動待機

弊社の「速いもん」のように、不動産サイト上にボタンや機能を追加するタイプの拡張機能だと、「ページが表示されてから、拡張がボタンを追加するまで待つ」必要があります。

Playwrightには自動待機（Auto-Wait）という機能があり、要素が操作できる状態になるまで自動で待ってくれます。Puppeteerの場合は、待機の指示を自分で書く必要があります。

1箇所だけなら大した差ではないですが、テストケースが増えてくると地味に手間が変わってきます。

テストランナーの有無

テストランナーとは、テストコードを実行して「成功・失敗」を判定してくれるツールです。テストファイルを見つけて順番に実行したり、失敗した場合にリトライしたり、結果をレポートとして出力してくれます。

Playwrightにはこのテストランナーが最初から入っています。Puppeteerには入っていないので、Jestなど別のツールを自分で用意して組み合わせる必要があります。

4. 公式ドキュメント・情報量の比較

	Playwright	Puppeteer
公式ドキュメント	◎ Chrome拡張の専用ページあり	△ 拡張に特化したページはない
Chrome拡張テストの日本語情報	◎ 増えてきている	○ 少なめ
ツール全体の情報量	○ 成長中（GitHub Stars 約68k）	◎ 豊富（GitHub Stars 約89k）

5. CI/CDへの組み込みやすさ

CI/CDとは、コードの変更を自動でテスト・デプロイする仕組みのことです。例えば「コードをGitHubにプッシュしたら、自動でE2Eテストが走って、問題なければ本番に反映される」という流れを作れます。

テストを毎回手動で実行するのは手間がかかるので、CI/CDに組み込んで自動化するのが理想です。

Playwright

PlaywrightはCI/CDを最初から意識した設計になっている印象です。

GitHub Actionsとの連携が簡単です。Playwright公式がセットアップ用のテンプレートを用意してくれているので、CI/CDへの導入がスムーズです
テスト結果のレポートをHTMLで自動生成してくれるので、どのテストが通ってどれが落ちたか一目で分かります
テストの並列実行に対応していて、複数のテストを同時に走らせることで実行時間を短縮できます
失敗時の記録として、スクリーンショットや動画を自動で残せます。「なぜ落ちたのか」を後から確認できるので、原因調査が楽になります

Chrome拡張のテストは、タイミングのズレで失敗することがあります。コンテンツスクリプトはページの読み込みが完了した後に動き始めますが、ページの読み込み速度はサイトやネットワーク状況によってバラバラです。そのため「ページは表示されたけど、拡張がまだボタンを追加していない」というタイミングが生まれ、テストが失敗する場合があります。Playwrightだとテストが失敗した時に自動でやり直したり、失敗時の画面を動画で残してくれるので、原因を調べやすいです。

Puppeteer

PuppeteerでもGitHub Actionsで動かすことはもちろんできます。ただ、テストランナーが内蔵されていないので、以下のようなことを自分で用意する必要があります。

テストを実行するためのツール（Jest等）を別で用意して組み合わせる必要があります
テスト結果をレポートとして見られるようにするためのライブラリを追加する必要があります
複数のテストを同時に走らせるための設定を自分で書く必要があります
テストが失敗した時にスクリーンショットを残す仕組みを自分で作る必要があります

自由度が高い分、チームの好みに合わせた構成にできるというメリットはあります。ただ、ゼロからセットアップするとなると、Playwrightに比べてやることが多いです。

6. 結論：どちらを選ぶか

ここまでの比較をまとめてみました！

比較ポイント	Playwright	Puppeteer
テストの書きやすさ	自動待機やシンプルなAPIで手間が少ない	できるが、自分で書く部分が多い
Chrome拡張テストの公式ドキュメント	専用ページがあり、サンプルコード付きで充実	拡張テストに特化したページがない
Chrome拡張テストの日本語記事	QiitaやZennで増えてきている	少なめ
CI/CDへの組み込み	テストランナーやレポートが最初から入っている	自分でツールを選んで構築する必要がある

結論としては、どちらでもChrome拡張のテストはできるという印象です。拡張をブラウザに読み込ませる仕組みは同じなので、どちらを選んでも大きく困ることはなさそうです。

その上で、自分はPlaywrightの方がとっつきやすいと感じました。理由は3つです。

1. 公式ドキュメントの手厚さ

Chrome拡張のE2Eテスト自体がまだ情報の少ない分野です。困ったときに頼れる公式ドキュメントがまとまっているのは、特に初めて取り組むチームにとって安心感があります。

2. CI/CDへの組み込みやすさ

ゆくゆくはGitHub Actionsで自動実行したいので、テストランナー・レポート・リトライが最初から入っているのは助かります。Chrome拡張のテストは不安定になりがちなので、失敗した時にスクリーンショットや動画で原因を確認できるのもポイントでした。

3. コンテンツスクリプトのテストでの自動待機

弊社の「速いもん」は複数の不動産サイトで動くので、サイトごとにページの読み込みタイミングがバラバラです。Playwrightの自動待機がこのタイミング問題を吸収してくれることを期待しています。

こういう場合はPuppeteer(パペティア)もアリかも？

Puppeteer(パペティア)の方が向いているケースもあると思います。

すでにPuppeteer(パペティア)を使っている場合は、わざわざPlaywrightに乗り換える必要はないと思います。使い慣れたツールの方が効率が良いこともあります
テストの実行ツールを自分で選びたい場合は、Puppeteer(パペティア)の方が向いている気がします。Playwrightはテストランナーが内蔵されていますが、Puppeteerは内蔵されていない分、Jestなど好きなツールと自由に組み合わせられます