Playwright Validation Skill
SkillWeb & browsingA 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.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
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
- Have the branch with the UI changes checked out and a running instance of the app to test against.
- Make sure Playwright and its MCP browser tools are available in the environment.
- Ask the agent to use the playwright-validation skill on the branch.
- Let the agent review the diff, inspect existing tests, and validate the UI in the browser.
- 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
-
Identify changed files vs main:
git diff main --stat git diff main --name-only | grep -E "\.(tsx?|less|css|scss)$" -
Focus on UI component changes:
git diff main -- "openmetadata-ui/src/main/resources/ui/src/components/**" --stat -
Check for existing Playwright tests:
git diff main --name-only | grep -E "playwright.*\.spec\.ts$" -
Read the changed component files to understand the UI modifications
Phase 2: Review Existing Playwright Tests
-
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
- Check
-
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
-
Review test utilities:
- Check
playwright/utils/for helper functions - Check
playwright/support/for entity classes and fixtures
- Check
Phase 3: Validate with Playwright MCP
-
Start the browser and navigate:
mcp__playwright__browser_navigate to http://localhost:8585 -
Authenticate if needed:
- Use
mcp__playwright__browser_fill_formfor login - Default admin:
admin@open-metadata.org/admin
- Use
-
Navigate to the feature area:
- Use
mcp__playwright__browser_clickfor navigation - Use
mcp__playwright__browser_snapshotto inspect page state
- Use
-
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
-
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
-
Create a TodoWrite checklist of missing test scenarios
-
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 }); }); -
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)
-
Run Playwright lint check:
yarn lint:playwrightEvery
playwright/*andom-playwright/*guardrail rule iserrorseverity. Repo-wideopenmetadata-playwright/*rules set their own, and may sit atwarnwhile 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:playwrightpasses with zero errors - No
networkidle,page.pause(), ortest.only()usage (blocked by ESLint) - Test fixtures are properly created and cleaned up
- Test timeouts use
test.slow()(preferred) ortest.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
github.com/open-metadata/openmetadata
Related picks
Skill · mattpocock
The pick for TypeScripttypescript-providers
Skill · composiohq
The pick for TypeScripte2e-testing
Skill · thedaviddias
The pick for End-to-end testinge2e-environment-preflight
Skill · sno-ai
The pick for End-to-end testingbrowser-use
Skill · browser-use
More in Web & browsingwebapp-testing
Skill · anthropics
More in Web & browsing