自動化テスト
なぜ Puppeteer はエンドツーエンドテストに適したツールなのか ?
ウェブベースの自動エンドツーエンドテストには豊富なエコシステムが存在します。したがって、「なぜ Gutenberg は(Cypress でも Selenium でも Playwright でもなく、Puppeteer を使うのか ?」はよくある質問です。 エンドツーエンドテストのビルド結果に対する、歴史的な信頼性の低さを考えると、この質問に答える場合、そのツールがテストの維持に必要な労力よりも多くの価値を提供するかどうかで検討することが自然でしょう。最初に下した決定を変更することに何の抵抗もありませんが、エンドツーエンドテストで利用可能な選択肢の中で、Puppeteer が最適解である理由はこれまでもこれからも数多くあります。
- 既存のテストフレームワークとの相互運用性: Puppeteer は Chromeブラウザを制御する「単なる」ツールに過ぎず、テスト環境への統合に前提を置きません。したがって、テスト環境の構築には追加の労力が必要になる一方で、既存のセットアップとの統合には一貫性を持たせられます。例えば Gutenbergは、ユニットテストとエンドツーエンドテストの両方に Jest を一貫して使用できます。これは、Cypress のような独自のテストフレームワークやアサーションライブラリをオールインワンで提供するソリューションとは対照的です。
- 表現力がありながら、予測可能なAPI: Puppeteer はバランスに優れます。ブラウザの動作への低レベルアクセスと、最新のJavaScript 構文
asyncとawaitを使用してコマンドを発行し、応答を待機する、表現力豊かなAPIの両方を提供します。これは、ネイティブ言語の非同期機能をサポートしないか活用しなかったり、ブラウザへの直接アクセスを公開しなかったり、ブラウザのコマンドやアサーションの表現に独自のカスタム言語構文を使用する他のソリューションとは対照的です。Puppeteer がほぼ Chrome ブラウザのみを対象としていることは、サポートするブラウザの種類という点で理想的ではありません。しかし一方、対象のブラウザを限定することで、より一貫した結果が得られ、ブラウザ環境でコードがどのように評価されるかをより強く保証できます。 - バグの隠蔽ではなく表出化: 多くの代替ソリューションでは、ネットワーク要求の解決や、ページ上の要素の非同期な表示に対して、自動で待機するオプションを提供します。これは、予期しない遅延に対処する便利な機能ですが、知らず知らずのうちに、ユーザーの正当な問題を見落とすことがあります。例えば、ネットワーク要求や計算の完了した後でのみページに要素が表示される場合、これがユーザーにとって予測不可能で苛立たしい遅延ある事実を見落とすかもしれません (例)。また、開発者は多くの場合、ハイエンドのハードウェアと、安定したネットワーク接続環境でテストを行うため、ローエンドのハードウェアや不安定なネットワーク状況への考慮は最優先事項ではありません。Puppeteer では、この遅延を明示的な
waitFor*表現で認識させることで、エンドユーザーの実体験との整合性を高めます。 - デバッグ。テストが失敗した際、問題を診断し、解決するわかりやすい手段があることは重要です。Puppeteer は競合に比べて、かなりシンプルなサービスを提供していて、テストを「ヘッドフル」(ブラウザが見える状態) で実行したり、遅延アクションを実行するオプションを公開しています。また、ネイティブ言語やランタイム機能 (デバッガーステートメントやブレークポイントなど) との相互運用性も高く、開発者にとって十分なデバッグ環境を提供します。
詳細は以下の資料を参照ください。
- テスト概要: エンドツーエンドテスト
- テスト: 実験 – Puppeteer と E2E テスト
- 初期のイテレーションで、コントリビューションチームはエンドツーエンドテストに Cypress の使用を選択しました。この pull request では、このアプローチの問題点を説明し、Puppeteer への最初の移行を提案しています。
- JavaScript Chat Summary: January 28, 2020
- Playwright は、 Puppeteerのオリジナルのコントリビューターの多くによって作られた新しい製品です。ブラウザのサポート率を増やし、テストの信頼性を向上しています。この記事の執筆時点ではまだ開発の初期段階ですが、将来的にエンドツーエンドテストのソリューションとして使用できるか評価への興味が持たれています。
最終更新日: