playwright-validation

Playwright 検証スキル

このスキルでは、UI の変更を検証し、包括的な Playwright E2E テストのカバレッジを確保する方法を説明します。

使用するタイミング

• UI 機能の開発完了後
• UI の変更に関する PR を作成する前
• UI 関連のブランチをレビューするとき
• 既存の Playwright テストがすべてのシナリオを網羅しているか確認するとき

ワークフロー

フェーズ 1：ブランチの変更を確認する

1. main と比較して変更されたファイルを特定します：

   git diff main --stat
   git diff main --name-only | grep -E "\.(tsx?|less|css|scss)$"
   

2. UI コンポーネントの変更に注目します：

   git diff main -- "openmetadata-ui/src/main/resources/ui/src/components/**" --stat
   

3. 既存の Playwright テストを確認します：

   git diff main --name-only | grep -E "playwright.*\.spec\.ts$"
   

4. 変更されたコンポーネントファイルを読み、UI の変更内容を把握します

フェーズ 2：既存の Playwright テストを確認する

1. 関連するテストファイルを特定します：

   • ページ単位のテストは playwright/e2e/Pages/ を確認します
   • 機能固有のテストは playwright/e2e/Features/ を確認します
   • Glob/Grep を使って、機能に関連するテストを探します

2. テストのカバレッジを分析します：

   • 既存のテストファイルを読みます
   • すでに網羅されているテストシナリオを特定します
   • UI の変更に基づき、カバレッジの不足箇所を確認します

3. テストユーティリティを確認します：

   • ヘルパー関数は playwright/utils/ を確認します
   • エンティティクラスとフィクスチャは playwright/support/ を確認します

フェーズ 3：Playwright MCP で検証する

1. ブラウザーを起動して移動します：

   mcp__playwright__browser_navigate to http://localhost:8585
   

2. 必要に応じて認証します：

   • ログインには mcp__playwright__browser_fill_form を使います
   • デフォルトの管理者：[email protected] / admin

3. 機能の該当エリアに移動します：

   • 移動には mcp__playwright__browser_click を使います
   • ページの状態を確認するには mcp__playwright__browser_snapshot を使います

4. UI の動作を検証します：

   • 主なユーザーフローをテストします
   • 視覚要素（アイコン、バッジ、ラベル）を確認します
   • インタラクティブ要素（ボタン、ドロップダウン、フォーム）を確認します
   • 状態の変化と API 呼び出しを検証します

5. 調査結果を記録します：

   • 正しく動作する点を記録します
   • 問題や不足している機能を特定します
   • 既存のテストでカバーされていないシナリオを列挙します

フェーズ 4：不足しているテストケースを追加する

1. 不足しているテストシナリオのチェックリストを TodoWrite で作成します

2. 不足しているテストケースごとに、次の手順を実施します：

   a. beforeAll に必要なテストフィクスチャを追加します：

   • 新しいエンティティインスタンス（TableClass、DataProduct など）を作成します
   • 必要な関連付け（ドメイン、アセット）を設定します

   b. afterAll にクリーンアップを追加します：

   • 作成したエンティティを逆の順序で削除します

   c. 次のパターンに従ってテストを記述します：

   test('Descriptive Test Name - What it validates', async ({ page }) => {
     test.setTimeout(300000);
   
     await test.step('Step description', async () => {
       // Test actions and assertions
     });
   
     await test.step('Next step', async () => {
       // More actions and assertions
     });
   });
   

3. カバーするテストパターン：

   • ハッピーパス（期待される動作）
   • エッジケース（空の状態、最大値）
   • エラー処理（無効な入力、リクエストの失敗）
   • 状態遷移（アクションの前後）
   • UI フィードバック（読み込み状態、成功／エラーメッセージ）
   • 権限（無効化されたボタン、制限された操作）

4. Playwright の lint チェックを実行します：

   yarn lint:playwright
   

   playwright/* と om-playwright/* のガードレールルールはすべて error 重大度です。リポジトリ全体の openmetadata-playwright/* ルールはそれぞれ独自の重大度を設定しており、呼び出し箇所の移行中は warn になっている場合があります。重大度を推測せず、ハンドブックの ESLint Enforcement テーブルにある重大度列を確認してください。

よく使うテストユーティリティ

ナビゲーション

import { sidebarClick } from '../../utils/sidebar';
import { redirectToHomePage } from '../../utils/common';
import { selectDataProduct, selectDomain } from '../../utils/domain';

待機

import { waitForAllLoadersToDisappear } from '../../utils/entity';
await waitForAllLoadersToDisappear(page);
await expect(page.getByTestId('content')).toBeVisible();
// NEVER use: page.waitForLoadState('networkidle') — blocked by ESLint

API レスポンス

const response = page.waitForResponse('/api/v1/endpoint*');
await someAction();
await response;
expect((await response).status()).toBe(200);

アサーション

await expect(page.getByTestId('element')).toBeVisible();
await expect(page.getByTestId('element')).toContainText('text');
await expect(page.locator('.class')).not.toBeVisible();

完了前のチェックリスト

• すべての UI の変更に対応するテストカバレッジがある
• テストで成功シナリオと失敗シナリオの両方をカバーしている
• テストで視覚的なインジケーター（アイコン、バッジ、状態）を検証している
• テストで API とのやり取りを検証している
• yarn lint:playwright がエラーなしで通る
• networkidle、page.pause()、test.only() を使用していない（ESLint によりブロックされます）
• テストフィクスチャが適切に作成され、クリーンアップされている
• テストのタイムアウトには test.slow()（推奨）または test.setTimeout() を使用している

例：データコントラクトの継承テスト

参考として、次のファイルにある包括的なテストカバレッジを参照してください。 playwright/e2e/Pages/DataContractInheritance.spec.ts

このファイルでは、次の内容を紹介しています。

• beforeAll での複数エンティティの設定
• ドメイン割り当てのパッチ処理
• コントラクトの作成と検証
• 継承アイコンの検証
• アクションボタンの状態の検証（無効／有効）
• API レスポンスの検証（POST と PATCH の比較）
• フォールバック動作のテスト