[公式Best Practices](https://playwright.dev/docs/best-practices)をベースに、自身の解釈や趣向も加えてベストプラクティスをまとめたもの。 基本的には #2023/05/05 現在の以下を和訳/要約してまとめたものである。 <div class="link-card-v2"> <div class="link-card-v2-site"> <img class="link-card-v2-site-icon" src="https://playwright.dev/img/playwright-logo.svg" /> <span class="link-card-v2-site-name">playwright.dev</span> </div> <div class="link-card-v2-title"> Best Practices | Playwright </div> <div class="link-card-v2-content"> Introduction </div> <img class="link-card-v2-image" src="https://repository-images.githubusercontent.com/221981891/8c5c6942-c91f-4df1-825f-4cf474056bd7" /> <a href="https://playwright.dev/docs/best-practices"></a> </div> また、[[📕tadashi-aikawa]]の個人的な見解によるものは、🦉マークをつける。 # [[E2Eテスト]]の哲学 ## ユーザーが見えるものと振る舞いをテストする [[E2Eテスト]]は『ユーザーが見えるもの・操作するもの』にフォーカスする。実装の詳細、たとえば[[CSSセレクター]]などはそれに該当しない。 ## できるだけ独立して実行できるようにする なるべく順序や状態、環境に依存せず実行できるようにする。調査やデバッグが簡単だから。 これを実現すると、テストの前処理や後処理が必要になる。処理が少なければ各テストケースに記載してもいいが、可読性が下がる場合は[[test.beforeEach]]などを利用するといい。 また、認証が必要で毎回ログインしなければいけない場合は、[[ブラウザコンテキストの状態を保存・復元 (Playwright)|ブラウザコンテキストの状態を保存・復元]]するとテストの実行時間を削減できる。 ## 1つあたりのテストは長く書き、テストの数は少なくする [[ユニットテスト]]のように、1つのテストで1つのことを確認するという思想は[[E2Eテスト]]には向かない。理由は以下の3点。 - テストの処理が遅くなり実行時間が長くなる - 起動や終了、ページロードにコストがかかるため - テストが失敗しても失敗箇所の特定が容易であり、失敗しても続けることすらできる - 🦉現実のシナリオは複数の機能があわさっており、それによって複合的な不具合を発見する可能性が高くなる ## サードパーティーに依存するテストは避ける 外部APIなどコントロール不可能なものを使ってのテストはしない。それらは実行速度が遅いだけではなく、制御が困難でテストの失敗が増えてしまう。 代わりに[[PlaywrightのネットワークAPI]]を使って、外部APIの挙動をハックしてしまえばいい。 ## [[データベース]]を使ってテストする [[データベース]]を操作する処理は、[[データベース]]がコントロール可能なステージング環境に対してテストを行い、[[データベース]]の結果が期待通りであるかを確認する。 > [!question] 原文と意図が違う気がする... > > > If working with a database then make sure you control the data. Test against a staging environment and make sure it doesn't change. # ベストプラクティス ## [[Locator]]を使う ### ユーザー向けの[[属性 (HTML)|属性]]を優先する ([[XPath]]や[[CSSセレクター]]よりも) ユーザーから見える方法で[[Locator]]を取得する。以下は`submit`と書かれたボタンのことであり、これはユーザーの見え方と一致する。 ```ts // 👍Good page.getByRole("button", { name: "submit" }) ``` 一方、[[CSSセレクター]]はユーザーが意識しないため望ましくない。 ```ts // 👎Bad page.locator('button.submit-icon') ``` ### [[Chaining Locators]]や[[Filtering Locators]]を使う [[Chaining Locators]]や[[Filtering Locators]]を利用した方がいい場合を見極めて使う。 - 🦉[[Filtering Locatorsとpage.getByTextの違い]] ## [[Locator]]をつくる ### [[Test generator]]を使う [[Playwright]]に同梱されている機能を使うなら、`playwright codegen`コマンドを実行して[[Test generator]]を立ち上げる。 ```console npx playwright codegen localhost:3000 ``` ### [[Playwright Test for VSCode]]を使う [[VSCode]]を使うなら[[Playwright Test for VSCode]]を使う。[[Locator]]の作成以外にも様々な機能があるため、[[VSCode]]の利用は強くオススメする。 ## Webファーストなアサーション [[playwrightのアサーション]]を使う。さもないと、期待値確認が即座に行われて期待通りの結果にならない。 ## デバッグの設定 ### ローカルデバッグ - [[Playwright Test for VSCode]]を使う - [[Playwright Inspector]]を使う ### CIデバッグ CIが失敗したときは、スクリーンショットやビデオではなく[[Trace Viewer]]を使う。 [[Trace Viewer]]で追跡可能にするためのオプションは[[playwright.config.ts]]で設定できる...が、常時このようにすることはパフォーマンスの観点からオススメしない。ローカルで実行する場合は必要な時だけ`--trace on`オプションをつけるのが良い。 ```console npx playwright test --trace on ``` `npx playwright show-report`コマンドでレポートを参照できる。 ## [[Playwright]]のツール群を使う 素晴らしいツールが助けになるので使おう。 - [[Playwright Test for VSCode]] - [[VSCode]]とのあらゆる連携 - [[Test generator]] - テストケースの生成や[[Locator]]のピックアップに - [[Trace Viewer]] - テスト結果の追跡..主にデバッグ目的で - [[TypeScript]]と[[IDE]] ## テストはすべてのブラウザで 実行時のプラットフォームに関係なく、設定すれば可能なので、様々なユーザーに対して動作保証するためにもすべてのブラウザでテストしよう。 ## [[Playwright]]の依存関係を最新に 以下のコマンドで最新にできる。 ```console npm install -D @playwright/test@latest ``` [[📚Playwrightのリリースノート]]をチェック。 ## CIでテストする 可能なら、[[並列]]実行や[[シャーディング]]する。 デフォルトで 以下のコマンドで、テストごとに[[並列]]実行することもできる。 ```ts test.describe.configure({ mode: 'parallel' }); ``` [[シャーディング]]は`--shard`オプションを使う。 ```console npx playwright test --shard=1/3 ```