Playwright vs. Puppeteer:スイッチするべきか?
Olivia Novak
Dev Intern · Leapcell

PuppeteerからPlaywrightへ:この移行は価値があるのか?
皆さん、こんにちは!PuppeteerからPlaywrightへの切り替えを検討するのに苦労していませんか?この移行はどれほど簡単または難しいのでしょうか?そして、本当に価値があるのでしょうか?コーディングレベルで予期せぬ変更はありますか?Playwrightにはどのような新しくて面白い機能が隠されているのでしょうか?ご心配なく。この記事では、これらの興味深いことについてお話します。
PuppeteerとPlaywrightの現状を大公開
一見すると、これら2つのツールには多くの類似点があります。しかし、ここ2年間で、開発速度は馬力の異なる2台のスポーツカーのようで、徐々に差が開いています。Playwrightは非常に精力的に開発されており、Puppeteerを凌駕しています。この強力な勢いが、多くの人々をPlaywrightに乗り換えさせています。この記事では、移行方法と、この変更が私たちにもたらすクールな新機能を詳しく説明します。記事は少し長いですが、内容は非常にシンプルで学びやすいです!
なぜ移行するのか?
以前にCypress、Selenium、Playwright、およびPuppeteerの比較テストを実施しました(詳細については、記事のリンクをクリックしてください)。簡単にまとめると、理由は次のとおりです。
- Playwrightは非常に頻繁に更新され、Puppeteerよりも多くの新機能があります!
- 実際のエン - ド - ツー - エンド(E2E)テストでは、Playwrightは優れたパフォーマンスを発揮し、非常に高速でテストケースを実行します(詳細については、記事のリンクを確認してください)!
- Playwrightは信頼できるパートナーのように、より安定しています。
- GitHub、Twitter、Slackなどのコミュニティでは、Playwrightは非常に人気がありますが、Puppeteerコミュニティは少し寂れているようです。
変更リストの比較
まず、比較表を見てみましょう。数分間目を通してから、後で詳しく見ていきます。
Puppeteer | Playwright |
---|---|
puppeteer.launch(...) | playwright.chromium.launch(...) |
browser.createIncognitoBrowserContext(...) | browser.newContext(...) |
page.setViewport(...) | page.setViewportSize(...) |
page.waitForSelector(selector) <br> page.click(selector); | page.click(selector) |
page.waitForXPath(XPathSelector) | page.waitForSelector(XPathSelector) |
page.$x(xpath_selector) | page.$(xpath_selector) |
page.waitForNetworkIdle(...) | page.waitForLoadState({ state: 'networkidle' }) |
page.waitForFileChooser(...) | 削除されました。処理方法が異なります。 |
page.waitFor(timeout) | page.waitForTimeout(timeout) |
page.type(selector, text) | page.fill(selector, text) |
page.cookies([...urls]) | browserContext.cookies([urls]) |
page.deleteCookie(...cookies) | browserContext.clearCookies() |
page.setCookie(...cookies) | browserContext.addCookies(cookies) |
page.on('request',...) | page.routeで処理 |
elementHandle.uploadFile(...) | elementHandle.setInputFiles(...) |
厄介なファイルのダウンロード。 | ダウンロードのサポートが向上。 |
変更の詳細を大公開
パッケージのインポート
Puppeteerでは、スクリプトの冒頭は次のようになります。
const puppeteer = require('puppeteer'); (async () => { const browser = await puppeteer.launch(); const page = await browser.newPage(); //...
Playwrightでは、次のようになります。
const { chromium } = require('playwright'); (async () => { const browser = await chromium.launch(); const page = await browser.newPage(); //...
Playwrightは非常に考慮されており、クロス - ブラウザサポートが付属しています。const { webkit } = require('playwright');
のように、実行するブラウザを自由に選択できます。Puppeteerでは、これはlaunchインターフェイスの構成を通じて実現する必要があります。例:
const browser = await puppeteer.launch({ product: 'firefox' })
ブラウザコンテキスト
Puppeteerでは、ブラウザコンテキストは次のように使用されます。
const browser = await puppeteer.launch(); const context = await browser.createIncognitoBrowserContext(); const page = await context.newPage();
Playwrightでは、コンテキストはさらに重要であり、使い方が少し異なります。
const browser = await chromium.launch(); const context = await browser.newContext(); const page = await context.newPage();
Puppeteerと同様に、基本的な使用または単一 - ページのフローの場合、デフォルトのコンテキストを使用できます。
const browser = await chromium.launch(); const page = await browser.newPage();
待機
Playwrightには強力な自動 - 待機メカニズムがあり、常に手動で待機する必要がない場合があります。ただし、待機はUI自動化で最も面倒な部分の1つであり、スクリプトが1つ以上の条件が満たされるまで従順に待機する方法を知っておく必要があります。この点に関して、Playwrightは次の変更をもたらしました。
page.waitForNavigation
とpage.waitForSelector
はまだありますが、自動 - 待機メカニズムにより、多くの場合、必ずしも必要ではありません。page.waitForEvent
が追加されました。- Puppeteerの
page.waitForXPath
はpage.waitForSelector
に統合されており、XPath式を自動的に認識できます。 page.waitForFileChooser
は削除されました。新しい使用法については、ファイルのアップロード、E2Eアカウント設定を参照してください。page.waitForNetworkIdle
はpage.waitForLoadState
に統合されました。page.waitForUrl
が追加されました。これにより、ページのメインフレームによってURLがロードされるのを待つことができます。page.waitFor(timeout)
がpage.waitForTimeout(timeout)
になります。page.waitForTimeout
は、正式な製品では使用しないでください。このハード待機はテストにのみ適していることに注意してください。
ビューポートの設定
Puppeteerのpage.setViewport
は、Playwrightではpage.setViewportSize
になります。
入力
Puppeteerのpage.type
は引き続き使用できます。細かいキーボードイベントを制御したい場合は、依然として優れたヘルパーです。また、Playwrightはpage.fill
を追加しました。これは、フォームの入力とクリアに非常に便利です。
クッキー
Puppeteerを使用する場合、クッキーはページレベルで処理されます。Playwrightでは、BrowserContextレベルで操作できます。 前:
page.cookies([...urls]) page.deleteCookie(...cookies) page.setCookie(...cookies)
現在:
browserContext.cookies([urls]) browserContext.clearCookies() browserContext.addCookies(cookies)
これらの方法には小さな違いがあるため、クッキーを渡すときは注意してください。
XPathセレクター
Playwrightは//
または..
で始まるXPathセレクターを自動的に認識できますが、Puppeteerには個別のインターフェースがあります。
デバイスのエミュレーション
Playwrightのデバイスエミュレーションは、次のようにブラウザコンテキストレベルで実行できます。
const pixel2 = devices['Pixel 2']; const context = await browser.newContext({ ...pixel2, });
また、権限、場所、その他のデバイスパラメーターも制御できます。クールですよね?
ファイルのダウンロード
ヘッドレスモードでのファイルのダウンロードはPuppeteerでは非常に面倒ですが、Playwrightでははるかに簡単です。
const [download] = await Promise.all([ page.waitForEvent('download'), page.click('#orders > ul > li:nth-child(1) > a') ]) const path = await download.path();
これは完全な例です。
ファイルのアップロード
PuppeteerのelementHandle.uploadFile
はelementHandle.setInputFiles
になります。詳細については、ファイルのアップロードの例を参照してください。
リクエストのインターセプト
Puppeteerでは、リクエストのインターセプトは次のように行われます。
await page.setRequestInterception(true) page.on('request', (request) => { if (request.resourceType() === 'image') request.abort() else request.continue() })
Playwrightでは、page.route
を使用して、指定されたパターンのURLをインターセプトできます。
await page.route('**/*', (route) => { return route.request().resourceType() === 'image' ? route.abort() : route.continue() })
完全な例については、こちらをご覧ください。
注意すべき新機能
PuppeteerからPlaywrightに切り替える場合は、Playwrightの新機能をよく理解する必要があります。これにより、テストまたは監視セットアップに新たな驚きをもたらす可能性があります!
新しいセレクターエンジン
Playwrightは、UI要素を参照するための非常に柔軟な方法を提供します。cssおよびXPathに加えて、次のものもあります。
- Playwright - 固有のセレクター(例:
:nth - match(:text("Buy"), 3)
)。 - テキストセレクター(例:
text=Add to Car
)。 - チェーンセレクター(例:
css=preview >> text=In stock
)。 独自のカスタムセレクターエンジンを作成することもできます。セレクターの詳細と使用法については、セレクターの操作を参照してください。
状態の保存と再利用
Playwrightは、特定のセッションの認証状態(クッキーとlocalStorage)を簡単に保存でき、スクリプトを次回実行するときに直接使用できるため、認証時間を節約できます。とても思いやりがありますよね?
Locator API
PlaywrightのLocator APIは、特定の要素を取得するロジックをカプセル化するため、さまざまな時点のスクリプトで最新のDOM要素を簡単に取得できます。
Inspector
PlaywrightのInspectorは、スクリプトのデバッグ時に非常に役立つGUIツールです。スクリプトで命令をステップごとに実行できるため、エラーの原因を簡単に見つけることができます。
Test
Playwrightには、E2Eテストで非常に役立つTestメカニズムがあります。たとえば、すぐに使用できる並列化、フックなどです。
Trace Viewer
PlaywrightのTrace Viewerを使用すると、PlaywrightテストまたはBrowserContext追跡APIによって記録されたトレースを調べることができます。追跡を通じて、スクリプトの実行を明確に確認できます。
Test Generator
PlaywrightのTest Generatorを使用して、ブラウザでのインタラクションを記録できます。出力は、チェックおよび実行できる完全なスクリプトです。
移行プロセス中の注意事項
PuppeteerからPlaywrightへの移行プロセスでは、上記で説明したさまざまな変更と新機能を理解することに加えて、特に注意する必要がある詳細がいくつかあります。
バージョンの互換性の問題
Playwrightをインストールして使用する場合は、そのバージョンがプロジェクトで使用されている他の依存ライブラリと互換性があることを確認してください。Playwrightのバージョンが異なると、APIの使用方法や機能にわずかな違いがある場合があります。したがって、公式ドキュメントを注意深く参照し、プロジェクトに適したバージョンを選択してください。同時に、Playwrightと使用しているブラウザのバージョンとの互換性にも注意してください。一部の新機能では、特定のバージョンのブラウザが適切に実行される必要があります。
構成の調整
移行後、一部の構成に対応する調整が必要になる場合があります。たとえば、Puppeteerでは、特定の起動パラメーターと構成オプションに慣れている場合がありますが、Playwrightでは、構成方法とパラメーター名が異なる場合があります。ヘッドレスモードを有効にするかどうか、プロキシを設定するかどうか、ブラウザのパフォーマンスパラメーターを調整するかなど、Playwrightのドキュメントに従ってブラウザを起動するための構成を再 - 設定する必要があります。
エラー処理
Playwrightのエラー - 処理メカニズムも、Puppeteerのものとは異なります。移行プロセス中に、コードがPlaywrightによってスローされるさまざまな例外を正しくキャッチして処理できることを確認してください。Playwrightのエラーメッセージには通常、詳細なエラーの理由とスタックトレースが含まれており、問題を迅速に特定して解決するのに役立ちます。try - catchステートメントを使用して例外をキャッチし、さまざまなエラータイプに応じてそれらを処理できます。たとえば、操作の再試行、エラーメッセージのログ記録などです。
チームコラボレーション
プロジェクトがチーム - コラボレーション開発プロジェクトである場合は、Playwrightに移行するときに、すべてのチームメンバーがこれらの変更を認識していることを確認してください。チームトレーニングを実施して、Playwrightの新機能と使用方法を共有し、誰もが新しいツールにできるだけ早く慣れるようにすることができます。同時に、プロジェクトのコード仕様とドキュメントを更新して、チームメンバーがPlaywrightを使用する際に統一された標準に従うようにします。
移行後の最適化の提案
移行が完了した後、作業は終わりではありません。Playwrightの利点を最大限に活用するには、コードを最適化することもできます。
並列化機能を活用する
PlaywrightのTestメカニズムは、すぐに使用できる並列化を提供し、テストケースの実行時間を大幅に短縮できます。プロジェクトの実際の状況に応じて、並行して実行するテストケースの数を合理的に構成し、マルチ - コアCPUのパフォーマンスを最大限に活用し、テスト効率を向上させることができます。
待機戦略の最適化
Playwrightの自動 - 待機メカニズムはすでに非常に強力ですが、一部の複雑なシナリオでは、待機戦略をさらに最適化する必要がある場合があります。たとえば、ページ要素のロード特性に応じて、待ち時間を合理的に設定して、待ち時間が長すぎるためにテスト効率が低下することを回避します。同時に、ハード待ち時間を使用することは避け、要素が表示されるかクリック可能になるのを待つなど、よりインテリジェントな待機条件を使用するようにしてください。
リファクタリング
移行プロセス中に、Puppeteerで元々記述された一部のコードがPlaywrightでより簡潔かつ効率的に実装できることがわかる場合があります。この時点で、コードを適切にリファクタリングし、冗長なコードを削除し、コードの読みやすさと保守性を向上させることができます。同時に、Playwrightが提供する新機能を活用して、テストケースを最適化し、それらをより堅牢で信頼性の高いものにすることができます。
まとめ
PuppeteerからPlaywrightへの移行には、新しい変更を学習して適応するために時間とエネルギーを費やす必要がありますが、長期的には、それだけの価値があります。Playwrightは、パフォーマンス、安定性、および新機能の点で明らかな利点があり、テストおよび自動化タスクに高い効率とより良いエクスペリエンスをもたらします。移行の重要なポイントを習得し、移行プロセス中のさまざまな詳細に注意を払い、移行後にコードを最適化する限り、この移行を正常に完了し、Playwrightの助けを借りてプロジェクトを新しいレベルに到達させることができます!
Leapcell: Webホスティング、非同期タスク、およびRedis向けの次世代サーバーレスプラットフォーム
最後に、Playwrightのデプロイに最適なプラットフォームLeapcellをお勧めします。
1. 複数の言語のサポート
- JavaScript、Python、Go、またはRustで開発。
2. 無制限のプロジェクトを無料でデプロイ
- 使用量に対してのみ支払い - リクエストなし、料金なし。
3. 比類のないコスト効率
- アイドル料金なしの従量課金制。
- 例:25ドルで平均応答時間60msで694万リクエストをサポートします。
4. 合理化された開発者エクスペリエンス
- 簡単なセットアップのための直感的なUI。
- 完全に自動化されたCI/CDパイプラインとGitOps統合。
- 実用的な洞察のためのリアルタイムメトリックとログ。
5. 簡単なスケーラビリティと高いパフォーマンス
- 高い同時実行を容易に処理するための自動 - スケーリング。
- 運用オーバーヘッドゼロ - 構築に集中するだけです。
Leapcell Twitter: https://x.com/LeapcellHQ