laywright の「公式の実行フロー」を最短で理解できるように整理して理解してみましょう。
これを学習すると、Playwright 全体がスッと理解できるようになります。
1. 「Test Runner」が全てを管理
Playwright は test runner（@playwright/test）を使うことで、 テストの実行・並列化・レポート生成などをまとめて面倒みてくれる。テストファイル
import { test, expect } from '@playwright/test';
test('sample', async ({ page }) => {
await page.goto('https://example.com');
});
ポイント
・test() がテストケースを定義 ・第2引数の { page } を Playwright が自動生成して渡す ・ブラウザ起動・ページ生成も test runner が面倒を見る 自分でブラウザを起動する必要がないので、これだけで Selenium などより圧倒的にラク。2. 「Fixture」という概念
Playwright は fixtures（フィクスチャ） という仕組みで、テスト実行に必要なオブジェクトを注入している。 一言で言うと、「テストが必要なものを、それ以外の何物でもなく、適切に用意してくれるヘルパーオブジェクト」です。fixturesの利点
環境のセットアップとクリーンアップの抽象化: テストを実行する前の準備 (setup) と、実行後の後処理 (teardown) を一箇所にカプセル化します。 テストコード自体は、必要なリソース（ブラウザページなど）を使うことに集中でき、環境構築の複雑さから解放されます。 テストの分離と一貫性: フィクスチャはテストごとに隔離されます。 例えば、組み込みのpageフィクスチャを使うと、各テストはクリーンな、セッション情報のない新しいブラウザタブ（ページ）を受け取ることができます。 これにより、テスト間の依存関係を防ぎ、一貫した結果が得られます。 オンデマンドでの実行: テストが必要なフィクスチャのみがセットアップされます。 不要なフィクスチャは実行されないため、テストの効率が向上します。 再利用性: 一度定義したフィクスチャは、複数のテストファイルやテストケースで再利用できます。 依存関係の解決: あるフィクスチャが他のフィクスチャに依存するように定義できます。 Playwrightは依存関係を自動的に解決し、正しい順序でセットアップとクリーンアップを実行します。サンプルコード
import { test, expect } from '@playwright/test';
// test関数の引数（波括弧内）でフィクスチャ名を指定するだけで利用できます。
test('基本的なテスト', async ({ page, browserName }) => {
await page.goto('https://playwright.dev/');
await expect(page).toHaveTitle(/Playwright/);
console.log(`テスト実行ブラウザ: ${browserName}`);
});
ポイント
・テストごとに新しいページが作られる ・独立したコンテキストなので状態に依存しない ・CI でも安定して動く組み込み（Built-in）フィクスチャの例
Playwright Testには、すぐに使える便利なフィクスチャが標準で用意されています。| フィクスチャ名 | 説明 | スコープ |
|---|---|---|
| page | ブラウザタブを表す Page オブジェクト。 最も一般的に使用され、テストごとに新しいクリーンなページが提供されます。 |
test |
| context | ブラウザコンテキスト（シークレットウィンドウのようなもの）を表す**BrowserContext**オブジェクト。 同じコンテキスト内のページはCookieなどを共有します。 テストごとに隔離されます。 |
test |
| browser | ブラウザインスタンス（Chromium, Firefox, WebKitなど）を表す Browser オブジェクト。 テストワーカー間で共有され、効率的です。 |
worker |
| browserName | 現在テストが実行されているブラウザの名前（例: 'chromium'）。 | worker |
| request | APIコールを行うための APIRequestContext オブジェクト。 | worker |
3. BrowserContext（ブラウザの“分身”）がテストの最小単位
Playwright ではブラウザ本体を直で触らず context を使って行います。BrowserContext の役割：
・クッキー ・ローカルストレージ ・セッション ・パーミッション ・storageState（ログイン維持）「1テスト = 1 context」 が基本運用。
4. Page は「タブ」＝ UI 自動操作のメイン対象
page はユーザーの操作そのものと理解しましょう。よく使うメソッド：
・page.goto() → ページ遷移 ・page.click() → クリック ・page.fill() → 入力 ・page.getByRole() → 要素取得 ・page.waitForResponse() → API待ちPage があるから、ユーザーと同じ体験を再現できる。
5. Locator が Playwright の核（超重要）
Playwright が Selenium などと違って「安定している理由」が Locatorです。サンプルコード
const name = page.getByLabel('名前');
await name.fill('Taro');
ポイント
・自動待機（要素が現れるまで待つ） ・再試行（リトライしてくれる） ・DOM 変化に強い これが Playwright の最大の強みであり、使うとテストが壊れにくくなる。6. Auto-wait（自動待機）がテスト安定化の源泉
Playwright は自分で wait を書かなくても良いんです。Playwright のメソッド特性：
・要素が visible になるまで待つ ・click は “実際に押せる状態” まで待つ ・navigation を伴えば自動的に waitForNavigation ・input は ready になるまで待機ポイント：
・locator.waitFor() の使いどころ ・SPA の API待ちは page.waitForResponse() を適宜使う7. 非同期処理は「await」で完全に制御する
Playwright 全体は Promise ベースで構成されています。 次のポイントを守るだけでテストが驚くほど安定します。ポイント
・page.click() は必ず await ・expect() も「async」になる場合がある（toHaveURL 等） ・expect(locator).toBeVisible() は待機も含む
8. テストの流れの基本構成
test('flow', async ({ page }) => {
// ① ページ遷移
await page.goto('/login');
// ② 入力
await page.fill('#email', '...');
await page.fill('#password', '...');
// ③ 操作
await page.click('button[type=submit]');
// ④ 画面の状態検証
await expect(page).toHaveURL('/dashboard');
// ⑤ 要素検証
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
});
0 件のコメント:
コメントを投稿