Playwright Validation Skill

SkillWeb & browsing

A skill for validating UI changes in a branch with Playwright end to end testing. It reviews the branch diff, checks which Playwright tests already cover the changed components, drives a browser to confirm the new behavior, and writes any missing test cases. It is meant for use after UI feature work and before opening a pull request.

Then ask your AI: use the Playwright Validation Skill

Details

Instructions available. Your AI can read the instructions. Execution depends on the setup they require.

Have the branch with the UI changes checked out and a running instance of the app to test against.

What your AI can do with it

  • Review branch changes against main and list changed UI files
  • Find existing Playwright specs that cover the changed components
  • Drive a browser with Playwright MCP to validate UI behavior
  • Add missing Playwright test cases following repo patterns
  • Run the Playwright lint check and verify fixtures are cleaned up

Getting started

  1. Have the branch with the UI changes checked out and a running instance of the app to test against.
  2. Make sure Playwright and its MCP browser tools are available in the environment.
  3. Ask the agent to use the playwright-validation skill on the branch.
  4. Let the agent review the diff, inspect existing tests, and validate the UI in the browser.
  5. Review the test cases the agent adds, then run the Playwright lint check.

What this skill tells your AI

The instructions your AI receives, as published by open-metadata/openmetadata in skills/playwright-validation/SKILL.md and read by Ahel’s review.

This skill guides you through validating UI changes and ensuring comprehensive Playwright E2E test coverage.

When to Use

  • After completing UI feature development
  • Before creating a PR for UI changes
  • When reviewing UI-related branches
  • To verify existing Playwright tests cover all scenarios

Workflow

Phase 1: Review Branch Changes

  1. Identify changed files vs main:

    git diff main --stat
    git diff main --name-only | grep -E "\.(tsx?|less|css|scss)$"
    
  2. Focus on UI component changes:

    git diff main -- "openmetadata-ui/src/main/resources/ui/src/components/**" --stat
    
  3. Check for existing Playwright tests:

    git diff main --name-only | grep -E "playwright.*\.spec\.ts$"
    
  4. Read the changed component files to understand the UI modifications

Phase 2: Review Existing Playwright Tests

  1. Locate relevant test files:

    • Check playwright/e2e/Pages/ for page-level tests
    • Check playwright/e2e/Features/ for feature-specific tests
    • Use Glob/Grep to find tests related to the feature
  2. Analyze test coverage:

    • Read the existing test file(s)
    • Identify the test scenarios already covered
    • Note any gaps in coverage based on the UI changes
  3. Review test utilities:

    • Check playwright/utils/ for helper functions
    • Check playwright/support/ for entity classes and fixtures

Phase 3: Validate with Playwright MCP

  1. Start the browser and navigate:

    mcp__playwright__browser_navigate to http://localhost:8585
    
  2. Authenticate if needed:

    • Use mcp__playwright__browser_fill_form for login
    • Default admin: admin@open-metadata.org / admin
  3. Navigate to the feature area:

    • Use mcp__playwright__browser_click for navigation
    • Use mcp__playwright__browser_snapshot to inspect page state
  4. Validate UI behavior:

    • Test the main user flows
    • Verify visual elements (icons, badges, labels)
    • Check interactive elements (buttons, dropdowns, forms)
    • Verify state changes and API calls
  5. Document findings:

    • Note what works correctly
    • Identify any issues or missing functionality
    • List scenarios not covered by existing tests

Phase 4: Add Missing Test Cases

  1. Create a TodoWrite checklist of missing test scenarios

  2. For each missing test case:

    a. Add necessary test fixtures in beforeAll:

    • Create new entity instances (TableClass, DataProduct, etc.)
    • Set up required relationships (domains, assets)

    b. Add cleanup in afterAll:

    • Delete created entities in reverse order

    c. Write the test following the pattern:

    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. Test patterns to cover:

    • Happy path (expected behavior)
    • Edge cases (empty states, max values)
    • Error handling (invalid inputs, failed requests)
    • State transitions (before/after actions)
    • UI feedback (loading states, success/error messages)
    • Permissions (disabled buttons, restricted actions)
  4. Run Playwright lint check:

    yarn lint:playwright
    

    Every playwright/* and om-playwright/* guardrail rule is error severity. Repo-wide openmetadata-playwright/* rules set their own, and may sit at warn while their call sites migrate — read the severity column in the handbook's ESLint Enforcement table rather than assuming.

Common Test Utilities

Navigation

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

Waiting

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

API Responses

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

Assertions

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

Checklist Before Completion

  • All UI changes have corresponding test coverage
  • Tests cover both positive and negative scenarios
  • Tests verify visual indicators (icons, badges, states)
  • Tests validate API interactions
  • yarn lint:playwright passes with zero errors
  • No networkidle, page.pause(), or test.only() usage (blocked by ESLint)
  • Test fixtures are properly created and cleaned up
  • Test timeouts use test.slow() (preferred) or test.setTimeout()

Example: Data Contract Inheritance Tests

For reference, see the comprehensive test coverage in: playwright/e2e/Pages/DataContractInheritance.spec.ts

This file demonstrates:

  • Multiple entity setup in beforeAll
  • Domain assignment patches
  • Contract creation and validation
  • Inheritance icon verification
  • Action button state verification (disabled/enabled)
  • API response validation (POST vs PATCH)
  • Fallback behavior testing

Signals

GitHub stars
15k
Forks
2k
Last commit
Oct 2026

Questions

When should I use this skill?
Use it after completing UI feature development, before creating a PR for UI changes, when reviewing UI related branches, or to verify existing Playwright tests cover all scenarios.
What does the skill do with the branch changes?
It diffs the branch against main, filters for UI component files, reads the changed components, and checks which Playwright specs already cover them.
How does it validate the UI?
It uses Playwright MCP to open a browser, navigate to the feature area, and exercise the main user flows, checking visual elements, interactive controls, and state changes.
Advanced
Item type
skill
Key
playwright-validation
Source
github.com/open-metadata/openmetadata