テストの実行

  1. # 利用可能なすべてのテストを実行します。
  2. npm run test:e2e
  3. # ヘッディングモードで実行します。
  4. npm run test:e2e -- --headed
  5. # 特定のブラウザ(`chromium`、`firefox`、または`webkit`)でテストを実行します。
  6. npm run test:e2e -- --project=webkit --project=firefox
  7. # 単一のテストファイルを実行します。
  8. npm run test:e2e -- \<path_to_test_file\> # 例: npm run test:e2e -- site-editor/title.spec.js
  9. # デバッグ。
  10. npm run test:e2e -- --debug

Linuxで開発している場合、現在はヘッディングモードでWebkitブラウザをテストする必要があります。GUIで実行したくない場合や実行できない場合(例: グラフィックインターフェースがない場合)、コマンドの前にxvfb-runを追加して仮想環境で実行します。

  1. # 利用可能なすべてのテストを実行します。
  2. xvfb-run npm run test:e2e
  3. # Webkitテストのみを実行します。
  4. xvfb-run -- npm run test:e2e -- --project=webkit

VS Codeで編集している場合、テストの実行、作成、デバッグに役立つPlaywright拡張機能が見つかるかもしれません。

ベストプラクティス

ベストプラクティスガイドをお読みください。

$を禁止し、代わりにロケーターを使用する

実際、ElementHandleを返すAPIは推奨されていません。これには$$$$eval$$evalなどが含まれます。Locatorははるかに優れたAPIで、Playwrightのアサーションと一緒に使用できます。これは、ロケーターが遅延しており、約束を返さないため、ページオブジェクトモデルとも非常にうまく機能します。

アクセシブルなセレクターを使用する

可能な限り、getByRoleを使用してクエリを構築します。これにより、内部実装に依存せずにアクセシブルなクエリを書くことができます。

  1. // Select a button which includes the accessible name "Hello World" (case-insensitive).
  2. page.getByRole( 'button', { name: 'Hello World' } );

複雑なクエリを実行するためにチェーンすることもできます:

  1. // Select an option with a name "Buttons" under the "Block Library" region.
  2. page.getByRole( 'region', { name: 'Block Library' } )
  3. .getByRole( 'option', { name: 'Buttons' } )

使用方法の詳細については、公式ドキュメントを参照してください。

セレクターはデフォルトで厳密です

要素をクエリするためのより良いプラクティスを促進するために、セレクターはデフォルトで厳密です。つまり、クエリが複数の要素を返すとエラーが発生します。

テストユーティリティを過剰に使用しない、シンプルなユーティリティをインライン化する

  1. <a name="favor-page-object-model-over-utils"></a>
  2. ### ユーティリティよりもページオブジェクトモデルを優先する
  3. 上記のように、[ページオブジェクトモデル](https://playwright.dev/docs/test-pom)は特定のページで再利用可能なユーティリティ関数を作成するための推奨方法です。
  4. POMを使用する理由は、ユーティリティを名前空間の下にグループ化して、発見しやすく、使用しやすくするためです。実際、`````PageUtils`````は`````e2e-test-utils-playwright`````パッケージ内のPOMでもあり、グローバル変数の必要性を回避し、ユーティリティは`````this`````を使用して互いに参照できます。
  5. <a name="restify-actions-to-clear-or-set-states"></a>
  6. ### 状態をクリアまたは設定するためのアクションを再設定する
  7. テストの前後に状態を手動で設定するのは遅く、特にテスト間で何度も繰り返される場合は特にそうです。API呼び出しを介して設定することをお勧めします。[`````requestUtils.rest`````]と[`````requestUtils.batchRest`````]を使用して[REST API](/read/wordpress/62d9db168b1e9849.md)を呼び出し(必要に応じて`````requestUtils`````に追加します)。手動で設定するためのテストも追加する必要がありますが、それは一度だけテストすれば十分です。
  8. <a name="avoid-global-variables"></a>
  9. ### グローバル変数を避ける
  10. 以前のJest + Puppeteer E2Eテストでは、`````page`````と`````browser`````がグローバル変数として公開されていました。これにより、同じテスト内で複数のページ/タブがある場合や、複数のテストを並行して実行したい場合に作業が難しくなります。`````@playwright/test`````には[https://playwright.dev/docs/test-fixtures]の概念があり、`````page`````、`````browser`````、および他のパラメータをテストに注入できます。
  11. <a name="make-explicit-assertions"></a>
  12. ### 明示的なアサーションを行う
  13. 必要に応じて、1つのテストに挿入できるアサーションの数に制限はありません。可能な限り明示的なアサーションを行う方が良いです。たとえば、ボタンをクリックする前にその存在を確認したい場合、`````expect( locator ).toBeVisible()`````を実行してから`````locator.click()`````を実行できます。これにより、テストの流れが良くなり、読みやすくなります。
  14. <a name="common-pitfalls"></a>
  15. ## 一般的な落とし穴
  16. <a name="overusing-snapshots"></a>
  17. ### スナップショットの過剰使用
  18. <a name="cross-browser-testing"></a>
  19. ## クロスブラウザテスト
  20. デフォルトでは、テストはchromiumでのみ実行されます。異なるブラウザでテストを実行するために*タグ*を付けることができます。テストタイトルのどこかに`````@browser`````を使用して、そのブラウザで実行します。テストは常にデフォルトでchromiumで実行され、`````-chromium`````を追加してchromiumでのテストを無効にします。利用可能なブラウザは`````chromium`````、`````firefox`````、`````webkit`````です。
  21. ``````bash
  22. test( 'I will run in @firefox and @webkit (and chromium by default)', async ( { page } ) => {
  23. // ...
  24. } );
  25. test( 'I will only run in @firefox but not -chromium', async ( { page } ) => {
  26. // ...
  27. } );
  28. test.describe( 'Grouping tests (@webkit, -chromium)', () => {
  29. test( 'I will only run in webkit', async ( { page } ) => {
  30. // ...
  31. } );
  32. } );
  33. `