Playwrightの完全ガイド: テストからCI/CD統合まで
開発
テスト
Playwright

Playwrightの完全ガイド: テストからCI/CD統合まで

約1か月前
0 コメント
まる

機械学習エンジニア

Playwrightの完全ガイド: テストからCI/CD統合まで

PlaywrightはWebアプリケーションの自動テストを強力にサポートするツールですが、基本的なE2Eテストにとどまらず、さまざまな高度なテストや開発ワークフローにも適用できます。本記事では、Playwrightをさらに活用するための高度なテスト技術、デバッグ手法、CI/CDへの統合、実プロジェクトでの活用事例、そして拡張機能・プラグインについて詳しく解説します。
E2Eテスト

E2Eテスト

高度なテスト技術

Playwrightは従来のUIテスト以外にも、多岐にわたるテスト手法を一つのフレームワーク内で実現できます。ここではAPIテストパフォーマンステスト視覚的回帰テストという3つの高度なテスト技術に注目します。

APIテスト

PlaywrightのテストランナーはAPIテスト機能を備えており、ブラウザを使ったE2Eテストと同じコードベースでREST APIなどのバックエンドテストを記述できます。例えば、テスト中にrequestオブジェクトを利用してHTTPリクエストを送り、そのレスポンスを検証することが可能です。以下のように、ユーザー一覧を取得するAPIを呼び出し、そのステータスやデータ内容を確認するテストを書けます。
JAVASCRIPT
const { test, expect } = require('@playwright/test'); test('API test', async ({ request }) => { const response = await request.get('https://api.example.com/users'); expect(response.ok()).toBeTruthy(); const users = await response.json(); expect(users.length).toBeGreaterThan(0); });
このようにブラウザ操作とAPI呼び出しを組み合わせることで、UIとサーバーサイドの両方を包括した包括的なシナリオを1つのテストスイートで実現できます。

パフォーマンステスト

パフォーマンステストでは、ページのロード時間やユーザー操作に対する応答時間など、アプリケーションの速度・性能要件を検証します。PlaywrightではDate.now()などを用いて処理時間を計測し、その値が許容範囲内かどうかをアサートすることで簡易的な性能テストを組み込めます。例えば、ページのロードが3秒以内に完了すること、重い操作が5秒以内に終わることを期待するテストを以下のように記述できます。
JAVASCRIPT
test('page load performance', async ({ page }) => { const startTime = Date.now(); await page.goto('https://example.com'); const loadTime = Date.now() - startTime; console.log(`Page load time: ${loadTime}ms`); expect(loadTime).toBeLessThan(3000); // ページロードが3秒未満 });
上記のようなテストにより、ページ表示やアクション処理の所要時間が事前に定めた閾値内に収まっているかを自動検証できます。性能劣化があればテストが失敗するため、パフォーマンスの退行を継続的に監視できます。また、必要に応じてPlaywrightと負荷テストツール(例:Artillery)の連携により大規模な同時リクエスト負荷シナリオを実行することも可能です。

視覚的回帰テスト

視覚的回帰テスト(ビジュアルリグレッションテスト)は、アプリケーションの画面レイアウトやデザインに意図しない変更が加わっていないかを検知するテスト手法です。Playwrightはスクリーンショットの比較機能を備えており、前回のテスト実行時からUIに変化がないことを検証できます。例えば、以下のように現在のページのスクリーンショットを撮影し、あらかじめ保存しておいたベースライン画像(スナップショット)と比較することで、UIの差分を検出できます。
JAVASCRIPT
test('visual regression test', async ({ page }) => { await page.goto('https://example.com'); const screenshot = await page.screenshot(); await expect(screenshot).toMatchSnapshot('homepage.png'); });
上記のtoMatchSnapshotを用いたテストでは、もしUIに変更があれば画像差分が検出されテストが失敗します。これにより、スタイル崩れやレイアウトの不具合を自動で検出し、リリース前に視覚的な品質を保証できます。さらに高度な視覚比較が必要な場合、Playwrightのスクリーンショット機能と外部サービス(PercyApplitoolsなどのビジュアルテストサービス)を組み合わせて、マルチブラウザでのピクセルレベルの比較やUI変更のレビューを行うことも業界で実践されています。

デバッグ手法

自動テストを開発・運用する上で、デバッグの効率化は非常に重要です。Playwrightはテストを容易にデバッグするための強力なツール群を提供しています。ここでは特にPlaywright Inspectorの活用ログの解析エラーハンドリングに焦点を当てます。
Playwright Inspector

Playwright Inspector

Playwright Inspectorによる対話的デバッグ

PlaywrightにはInspector(インスペクター)と呼ばれるGUIデバッグツールが内蔵されており、テストを対話的に実行・解析できます。このInspector上ではテストの各ステップをステップ実行したり、一時停止してその時点のページのDOMや状態を調べたりすることが可能です。一時停止中には要素選択ツールで適切なLocator(要素を特定するセレクタ)をGUI操作で取得する機能もあり、テストコードの修正に役立ちます。
Inspectorを使う方法として、コマンドラインでnpx playwright test --debugフラグを付与してテストを実行するだけで、自動的にデバッグモードとなりインスペクターが起動します。あるいは、テストコード中にawait page.pause()と記述しておけば、その行で実行が停止しインスペクターが起動します。この機能により、失敗箇所直前の状態で自由にブラウザを操作・検証できるため、原因調査が飛躍的に容易になります。

ログの解析とトレースビューア

テスト中に記録されるログトレースを活用することで、非同期処理の挙動や失敗原因を詳細に分析できます。Playwrightにはテスト実行の詳細な履歴を保存し後から再生できるトレースビューア機能があり、問題発生時のコンテキストを可視化できます 。例えば、playwright.config.jsの設定でtrace: 'on-first-retry'trace: 'on'と指定しておくと、テスト失敗時や常にトレースファイルが生成されます。生成されたtrace.zipnpx playwright show-trace trace.zipコマンドで開くと、各ステップのスクリーンショット、DOMスナップショット、ネットワークリクエスト、コンソールログなどを時間軸とともに確認できる専用ビューアが起動します。これにより、「どの操作の後にどんなエラーが起きたか」「期待した要素がなぜ操作できなかったのか」といった点を直感的に追跡できます。
また、Playwrightはブラウザ内部で発生したコンソールログやエラーを取得することも可能です。設定でブラウザログを有効化することで、テスト実行中にページ内でconsole.errorconsole.logに出力された内容をテストの標準出力に含めることができます 。例えば、以下の設定ではブラウザのコンソールメッセージをフィルタして収集し、テスト実行時に出力しています。
JS
// playwright.config.js の一部 use: { logger: { isEnabled: (name, severity) => name === 'browser', log: (name, severity, message) => console.log(`${name} ${message}`) } }
このようにしておけば、テスト失敗時に「ブラウザ側でJavaScriptエラーが発生していないか」「警告メッセージが出ていないか」といった情報をすぐに把握でき、原因追及に役立ちます。さらに、page.on('pageerror', err => {...})でページ内の未捕捉エラーイベントをフックし、スクリーンショット撮影や追加ログ出力を行うことも可能です。ログとトレースを駆使することで、CI上のようにリアルタイムで画面を見られない環境でも、問題の再現状況を詳細に再現・分析できます。

エラーハンドリングと再実行戦略

テストのエラーハンドリングとは、予期しうる失敗や環境依存の一時的な不具合に対して、テストを安定稼働させるための戦略です。Playwrightは自動待機(auto-wait)機能により、多くの場合で明示的な待機コードを書かなくても要素が現れるまで待ってくれます (自動テストでplaywrightを使ってみた)。しかし、それでも想定外のタイミング問題や一時的なネットワーク障害でテストが失敗することがあります。そのような一時的な失敗に対処するため、Playwrightのテストランナーにはテストの自動リトライ機能も組み込まれています。playwright.config.tsretriesを指定すれば、失敗したテストを指定回数まで自動再実行し、二度目以降で成功すれば最終的にはパスとみなすことが可能です(不安定なテストの影響を低減できます)。特にCI環境ではretries: 1と設定して一度リトライする運用が推奨されるケースがあります。
根本的なエラーの原因解消とは別に、失敗時の情報収集もエラーハンドリングの一環です。Playwrightでは前述のトレースに加え、テスト失敗時に自動でスクリーンショットを取得したり、動画を記録したりできます。設定でuse: { screenshot: 'only-on-failure', video: 'retain-on-failure' }等とすれば、テストが失敗した場合のみその時点の画面や操作動画が保存され、後から確認できます。これらの仕組みによって、エラー発生時にも十分なデータが残り、ローカルで再現が難しい問題でも原因を特定しやすくなります。
加えて、テストコード中でtry-catchを使い例外を捕捉してリカバリ処理を入れる、あるいは特定の手順が失敗したら代替手順を試みる、といったコードレベルのエラーハンドリングも状況に応じて行われます。例えば、ページ上に必ずしも存在しない要素をチェックする際には、await page.locator(selector).catch(e => {/*ハンドル*/})のようにしてテストがクラッシュしないようにする実装例もあります。総じて、Playwrightでは自動リトライや豊富なデバッグ情報の取得によって、テスト失敗の影響を抑えつつ迅速に原因を分析できる体制を構築できます。

CI/CDへの統合

Jenkins

Jenkins

Playwrightで作成したテストは、継続的インテグレーション/デリバリー(CI/CD)環境に容易に組み込むことができます。公式にも主要なCIサービス向けのサンプル設定が用意されており、3ステップ程度で基本的なCI実行が可能です。ここでは代表的なJenkinsGitHub Actionsへの統合事例について述べます。
Jenkinsの場合、Dockerを利用した統合がシンプルかつ再現性高く実現できます。Playwright公式が提供する専用のDockerイメージ(例えばmcr.microsoft.com/playwright:v<version>)をJenkinsエージェントとして使用すれば、必要なブラウザや依存関係が揃った環境でそのままテストを実行できます。
GROOVY
pipeline { agent { docker { image 'mcr.microsoft.com/playwright:v1.51.0-noble' } } stages { stage('e2e-tests') { steps { sh 'npm ci' sh 'npx playwright test' } } } }
上記のようにDocker上でplaywright testコマンドを走らせるだけで、ヘッドレスブラウザを用いたE2EテストがCI上でも再現性高く実行できます。Dockerコンテナを使うことで、ローカルとCIの環境差異を抑え、ブラウザの依存関係も自動で解決されます。
GitHub ActionsでもPlaywrightは簡単に導入できます。公式のガイドではUbuntuランナー上でブラウザをインストールして実行する例が紹介されていますが、より実践的にはDocker Compose等を用いてテスト対象アプリケーションとテストを同時起動する方法が取られています。あるプロジェクトでは、GitHub Actions上でまずDocker Composeでアプリケーション(サーバー)とデータベースを立ち上げ、その後Playwrightのテストコンテナを起動してE2Eテストを行う構成を採用しています ([Playwright を使ったE2Eテストの導入]。この方法により、以下のような利点が得られています:
  • アプリケーションのビルド・起動をワークフロー内で自動化し、本番に近い環境を毎回再現してテストを実行できる
  • Dockerによる隔離環境でテストを行うため、ローカル環境の違いに左右されず安定した結果が得られる
  • Dockerネットワークを利用することで、テストコードからアプリケーションコンテナやDBコンテナへの接続設定が簡素化される
実際のGitHub Actions設定例では、npx playwright install --with-depsで必要ブラウザをセットアップした後、npx wait-on tcp:8080 && npm run test:e2eのようにアプリ起動完了を待ってからテストを実行する工夫がされています。これにより、サーバー起動のタイミングによるテスト失敗を防いでいます。
なお、PlaywrightはGitLab CICircleCIAzure Pipelinesなど他のCIサービスとも統合可能です 。基本的なアプローチはどれも類似しており、「テスト実行環境にブラウザをインストールする(またはDockerイメージを利用)」「npx playwright testでテスト実行」「結果レポートを保存」という流れになります。CI上では並列実行を無効化または制限して安定性を高める設定が推奨されており、必要に応じてジョブを分割して並列度を高める(sharding)ことも可能です 。さらに、テスト結果のレポートをCIのアーティファクトやダッシュボードに保存すれば、失敗時の詳細確認も容易になります。例えばPlaywright純正のHTMLレポートを生成しCIからダウンロードできるようにしたり、Allure等のサードパーティレポートと連携してブラウザごとの詳細な結果を閲覧できるようにする運用も一般的です。

実際のプロジェクト事例

Playwrightは様々な企業やプロダクトでE2Eテスト自動化ツールとして採用が進んでおり、その事例からベストプラクティスが見えてきます。以下に業界ごとの活用例や得られた知見を紹介します。
フィンテック業界の事例: あるスタートアップ企業では、キャッシュレス決済サービスにおいてPlaywrightを導入し、QRコードを用いた決済フローのE2Eテストを自動化しました (Playwright を使ったE2Eテストの導入)。金融系の決済フローは複数の外部要素(例えばQRコード読み取りや決済ネットワーク)との連携が必要ですが、Playwrightによりブラウザ上でQRコード画像を表示させてスキャン処理を模擬するなどの工夫でE2Eテストを構築しています。その結果、リリース前に本番さながらの決済シナリオを高速・確実に検証できるようになりました。また、このプロジェクトではサービス開発初期から自動テストを導入したことで、仕様の明文化と共有、開発者の手動テスト負荷軽減に大きな効果があったと報告されています (Playwright を使ったE2Eテストの導入)。自動テストにより仕様がテストコードという形でドキュメント化され、新機能追加時も安心してリファクタリングできる体制を整えています。
Webサービス開発の事例: 別の企業のQAエンジニアチームでは、Playwright導入にあたり事前に**Design Docs(設計ドキュメント)**を作成し、なぜPlaywrightを選定しどう運用するかを整理してから導入しました (Playwrightを導入してみた話|iCARE QAEチーム)。このように事前に目的・方針・運用ルールを明確化することで、チーム内合意を得てスムーズにテスト自動化を開始できたといいます。また、導入後の実運用を通じて得られた具体的な成果として、以下のような点が挙げられています (Playwright を使ったE2Eテストの導入):
  • CIパイプラインにE2Eテストを組み込み、プルリクエストごとに自動でリグレッションテストを実行
  • コードレビュー時に開発者自身がテスト結果を確認できるようになり、動作確認の効率化
  • テストコードが生きたドキュメントとなり、新メンバーへの仕様共有や認識合わせに寄与
このように、開発プロセスに組み込まれたE2Eテストは品質ゲートとして機能し、バグの早期発見とチーム全体の品質意識向上につながっています。実際、あるプロジェクトでは依存ライブラリ更新時のリグレッションチェックが自動化され、手動確認に費やしていた時間を大幅に削減できたとの報告があります。
テスト設計のベストプラクティス: 大規模なプロジェクトでPlaywrightを運用する上でのベストプラクティスも蓄積されています。例えば、テストコードの保守性向上のために**ページオブジェクトモデル(POM)**パターンを採用するのは有効です。POMとは画面ごとの操作や要素をオブジェクトクラスにカプセル化し、テストシナリオからそれらを呼び出す設計手法で、Playwrightでももちろん実践可能です。POMを導入すると、UI変更時でもページオブジェクト内の実装を修正するだけで多くのテストケースを更新でき、テストコードの見通しも良くなります。実際にPlaywright導入企業の中には、後述する拡張機能(フィクスチャ)を活用してPOMを整備し、スケーラブルなテストスイートを構築している例があります。
また、認証やテストデータ管理など現実的なシナリオへの対処もポイントです。多くのWebアプリはログインが必要になるため、ログイン処理を一度行って以降のテストにセッション情報を引き継ぐ工夫や、テストごとにクリーンな状態を準備するセットアップ/ティアダウン処理が重要です。Playwrightはマルチセッション(コンテキスト)の管理やストレージ状態の保存・復元もできるため、例えば一度ログインしたクッキーを保存して複数テストケースで使い回すことで、認証にかかるオーバーヘッドを削減するといった最適化も可能です。
最後に、業界別ではありませんが既存ツールからの移行事例も増えています。あるケースでは、ノーコードのE2EテストサービスであるMablからPlaywrightへの移行を試験的に行い、テストコードのバージョン管理や開発者による保守性の高さ、そしてランニングコスト削減の可能性を評価しています。このように、プロダクトの成長やチーム体制に応じて最適なテスト手法を選択する動きの中で、Playwrightが有力な選択肢となっていることが伺えます。

拡張機能やプラグイン

Playwrightのエコシステムには公式・非公式を含めさまざまな拡張機能やプラグインが存在し、標準機能にとどまらない高度な活用を可能にしています。開発効率を高めるエディタ連携から、特殊なテストニーズに応えるコミュニティ製プラグインまで、その活用方法を見てみましょう。

VS Code公式拡張機能

VS codeのPlaywright拡張機能

VS codeのPlaywright拡張機能

Microsoft製の公式Visual Studio Code拡張機能は、Playwrightユーザにぜひ活用してほしいツールです。VS Code上でテストの記録・実行・デバッグをGUIで支援してくれる拡張で、コマンド一つでブラウザを立ち上げ実際の操作を記録し、そのままテストコードとして出力してくれます。例えば、拡張機能の「Record at cursor」機能を使うと、ブラウザでの操作を実行しながら対応するコードが自動生成されます。クリックや入力といった操作がその場でコード化されるため、手作業でセレクタを探して書くより格段にスピーディーです。さらにVS Code内のテストエクスプローラーからテストの実行やデバッグ(ブレークポイントを設定してのステップ実行)もできるため、IDEとPlaywrightが密接に統合された開発体験を得られます。テスト開発初心者でもGUIから操作を記録してみることでPlaywrightのコードパターンを学べる利点もあり、教育目的にも有用です。

Playwright Extraによるプラグイン拡張

コミュニティによって開発されたPlaywright Extraというライブラリを使えば、Playwright自体にプラグイン機構を導入して機能を拡張できます。Playwrightは強力ですが標準では拡張性に制限があるため、オープンソースコミュニティがplaywright-extraというラッパーを提供しており、プラグインを追加できるようになっています。このPlaywright Extraでは例えば、ステルスモード(自動テスト検知を回避するためのブラウザ設定)やCAPTCHA自動解決、プロキシ管理など、Webテストやスクレイピングでありがちな追加機能をプラグインとして組み込めます。Puppeteer向けに提供されていた有名なプラグイン(puppeteer-extra-plugin-stealthやreCAPTCHA回避プラグイン等)をPlaywrightでも利用できるようになっており、必要なプラグインを登録しておくだけでPlaywrightのブラウザ動作が拡張されます 。例えば、bot検知を避けたい場合にステルスプラグインを有効化すれば、Playwrightが人手による操作により近い挙動をとるよう細工してくれます。高度な自動化シナリオ(複雑なログインフローや、人間でないと解決が難しいチェック)にもこの仕組みが役立つでしょう。

その他のエコシステム活用

Playwright周辺のエコシステムには他にも多彩なツールが存在します。例えば、テスト結果の閲覧性を高めるレポーティング拡張では、AllureやJUnit形式のレポーターを導入してテスト完了後にリッチなHTMLレポートを生成することが一般的です。前述のようにJenkins等にAllureレポートを組み込めば、各テストのスクリーンショットやステップが可視化されたレポートをCI上のページから確認できます。また、**BDD(Behavior Driven Development)**手法を用いたい場合には、Cucumber.jsとPlaywrightを組み合わせることもできます。専用の統合パッケージを使えば、Gherkinで記述したシナリオをPlaywrightのステップ実装に紐付けて実行でき、非エンジニアの関与する受け入れテストを実現できます。さらに、クラウド上での大規模テスト実行にもPlaywrightは対応しており、BrowserStackやSauce LabsなどのクラウドテストサービスがPlaywrightをサポートしています。これらを利用すれば、様々なOS・ブラウザ環境での並列テストをスケーラブルに回すことができます。
最後に、Playwright自体も日々アップデートされ新機能が追加されています。たとえばComponent TestingAPIモックといった新たな領域にも拡張が進んでおり、公式ドキュメントやコミュニティの情報発信から目が離せません。Playwrightのエコシステムを積極的に活用し、自プロジェクトに合った機能拡張やツール統合を行うことで、テスト自動化の効率と効果を一層高めることができるでしょう。

まとめ

Playwrightは基本的なE2Eテストにとどまらず、APIテストの統合や性能測定、視覚的回帰チェックまで網羅できる万能な自動化テストフレームワークです。加えて、Inspectorを中心とした充実したデバッグ機能や、CI/CDパイプラインへのスムーズな統合により、開発ライフサイクルに溶け込んだテスト自動化を実現できます。実際の導入事例からは、テストの早期導入と継続的運用がプロダクト品質のみならず開発効率にも良い影響を与えることが示されています。さらに、VS Code拡張やコミュニティ製プラグインなどエコシステムを活用することで、Playwrightの機能を柔軟に拡張し、自社のニーズにフィットさせることも可能です。
エンドツーエンドの品質保証がますます重要になる中、Playwrightの高度な活用法をマスターして信頼性の高いテスト基盤を築き上げましょう。本記事の情報が、皆さんのプロジェクトにおけるPlaywright活用の一助になれば幸いです。
参考資料
最終更新: 2025年3月14日

コメント

まだコメントがありません