mcpField
P
playwright-validation

playwright-validation

github.com/open-metadataTesting & quality15.6k59 installsUpdated today
Repository

About playwright-validation

playwright-validation is a skill for reviewing UI changes and Playwright E2E coverage in OpenMetadata. It combines branch and test review with browser-based checks using Playwright MCP, then guides adding missing cases and running lint.

Key features

  1. 01Compares UI changes with main
  2. 02Finds and reviews related E2E tests
  3. 03Validates flows through Playwright MCP
  4. 04Identifies coverage gaps and edge cases
  5. 05Checks tests with the Playwright linter

Use cases

  1. 01Reviewing UI changes before a pull request
  2. 02Checking test coverage for a changed component
  3. 03Validating UI flows and API responses
  4. 04Adding tests for missing cases and permissions

MCP support

Uses Playwright MCP to navigate the browser, inspect page state, and exercise UI flows during validation.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/open-metadata/openmetadata --skill playwright-validation

After installing, type/playwright-validationin Claude Code to confirm it loaded.

Details

From the project README

Playwright Validation Skill

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: [email protected] / 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

Comments

Markdown supported