なぜPuppeteerはエンドツーエンドテストの選択ツールなのか?

Webベースのエンドツーエンド自動テストのための豊富なツールエコシステムが存在します。したがって、一般的な質問があります。「なぜGutenbergは(CypressSeleniumPlaywrightなどの代わりにPuppeteerを使用するのか?」。エンドツーエンドテストに関連するビルド結果の歴史的な信頼性の欠如を考慮すると、ツールがそれらを維持するために必要な努力以上の価値を提供しているかどうかを考える際に、この質問を考慮するのは特に自然です。以前の決定を再評価することに常に快適であるべきですが、Puppeteerがエンドツーエンドテストのための利用可能なオプションの中で最良の妥協である理由は多くあり、今も続いています。

これには以下が含まれます:

  • 既存のテストフレームワークとの相互運用性。Puppeteerは「単に」Chromeブラウザを制御するためのツールであり、テスト環境への統合方法については何の仮定もありません。このため、テスト環境が利用可能であることを確認するために追加の努力が必要ですが、既存のセットアップとの統合方法において一貫性を持たせることも可能です。Gutenbergは、ユニットテストとエンドツーエンドテストの両方にJestを一貫して使用することができます。これは、Cypressのような他のソリューションと対照的で、これらはオールインワンソリューションの一部として独自のテストフレームワークとアサーションライブラリを提供します。
  • 表現力豊かで予測可能なAPI。Puppeteerは、ブラウザの動作への低レベルアクセスと、現代のJavaScript asyncawait 構文を使用してコマンドに対する応答を発行し待機するための表現力豊かなAPIとの間で良いバランスを保っています。これは、他のソリューションと対照的で、これらはネイティブ言語の非同期機能をサポートまたは活用しない、ブラウザへの直接アクセスを公開しない、またはブラウザコマンドとアサーションを表現するためのカスタムドメイン固有言語構文を活用します。Puppeteerが主にChromeブラウザをターゲットにしているという事実は、完全なブラウザカバレッジを提供しない点で理想的ではありません。一方で、限られたブラウザターゲットのセットは、より一貫した結果と、ブラウザ環境でのコード評価に関する強力な保証を提供します。
  • バグを表面化させ、隠さない。多くの代替ソリューションは、ネットワークリクエストが解決されるのを自動的に待機したり、ページ上の要素の非同期的な出現を待機するオプションを提供します。これは予測できない遅延を考慮する上で便利ですが、正当なユーザー向けの問題を見落とす原因にもなり得ます。たとえば、要素がネットワークリクエストや計算が完了した後にのみページに表示される場合、これらの遅延がユーザーにとって予測不可能で苛立たしい動作を引き起こす可能性があることを見落とすのは簡単です()。開発者はしばしば高性能なハードウェアと安定したネットワーク接続でテストを行うため、低性能なハードウェアや不安定なネットワークの可用性に対する考慮は常に最前線にあるわけではありません。Puppeteerは、明示的なwaitFor*表現を使用してこれらの遅延を認識させ、エンドユーザーの実際の体験とより大きく一致させます。
  • デバッグ。テストが失敗した場合、問題を診断し解決するための簡単な手段が必要です。競合に対してその提供はかなり単純ですが、Puppeteerは「ヘッドフル」(ブラウザが表示されている状態)でテストを実行し、遅延アクションを伴うオプションを公開しています。ネイティブ言語/ランタイム機能(例:デバッガステートメントやブレークポイント)との相互運用性が良好であることと相まって、開発者に十分なデバッグアクセスを提供します。

さらなる文脈については、以下のリソースを参照してください:

  • テスト概要:エンドツーエンドテスト
  • テスト:E2EテストのためのPuppeteerを試す
    • 初期のイテレーションでは、貢献チームはエンドツーエンドテストにCypressを使用することを選択しました。このプルリクエストは、そのアプローチの問題を概説し、Puppeteerへの初期の移行を提案しました。
  • JavaScriptチャットサマリー:2020年1月28日
    • Playwrightは、Puppeteerの元の貢献者の多くによって作成された新しい提供物です。ブラウザカバレッジが増加し、テストの信頼性が向上します。この執筆時点ではまだ開発の初期段階ですが、将来のエンドツーエンドテストソリューションとしての評価に関心が寄せられています。