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
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
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
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_form for login
- Default admin:
admin@open-metadata.org / admin
Navigate to the feature area:
- Use
mcp__playwright__browser_click for navigation
- Use
mcp__playwright__browser_snapshot to inspect page state
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:playwright
Error-level rules (no-networkidle, no-page-pause, no-focused-test) will block CI. See the handbook's ESLint Enforcement section for the full rule reference.
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
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
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: playwright-validation3description: Use when validating UI changes in a branch require Playwright E2E testing. Reviews branch changes, validates UI with Playwright MCP, and adds missing test cases.4---56# Playwright Validation Skill78This skill guides you through validating UI changes and ensuring comprehensive Playwright E2E test coverage.910## When to Use1112- After completing UI feature development13- Before creating a PR for UI changes14- When reviewing UI-related branches15- To verify existing Playwright tests cover all scenarios1617## Workflow1819### Phase 1: Review Branch Changes20211. **Identify changed files vs main:**22 ```bash23 git diff main --stat24 git diff main --name-only | grep -E "\.(tsx?|less|css|scss)$"25 ```26272. **Focus on UI component changes:**28 ```bash29 git diff main -- "openmetadata-ui/src/main/resources/ui/src/components/**" --stat30 ```31323. **Check for existing Playwright tests:**33 ```bash34 git diff main --name-only | grep -E "playwright.*\.spec\.ts$"35 ```36374. **Read the changed component files** to understand the UI modifications3839### Phase 2: Review Existing Playwright Tests40411. **Locate relevant test files:**42 - Check `playwright/e2e/Pages/` for page-level tests43 - Check `playwright/e2e/Features/` for feature-specific tests44 - Use Glob/Grep to find tests related to the feature45462. **Analyze test coverage:**47 - Read the existing test file(s)48 - Identify the test scenarios already covered49 - Note any gaps in coverage based on the UI changes50513. **Review test utilities:**52 - Check `playwright/utils/` for helper functions53 - Check `playwright/support/` for entity classes and fixtures5455### Phase 3: Validate with Playwright MCP56571. **Start the browser and navigate:**58 ```59 mcp__playwright__browser_navigate to http://localhost:858560 ```61622. **Authenticate if needed:**63 - Use `mcp__playwright__browser_fill_form` for login64 - Default admin: `admin@open-metadata.org` / `admin`65663. **Navigate to the feature area:**67 - Use `mcp__playwright__browser_click` for navigation68 - Use `mcp__playwright__browser_snapshot` to inspect page state69704. **Validate UI behavior:**71 - Test the main user flows72 - Verify visual elements (icons, badges, labels)73 - Check interactive elements (buttons, dropdowns, forms)74 - Verify state changes and API calls75765. **Document findings:**77 - Note what works correctly78 - Identify any issues or missing functionality79 - List scenarios not covered by existing tests8081### Phase 4: Add Missing Test Cases82831. **Create a TodoWrite checklist** of missing test scenarios84852. **For each missing test case:**8687 a. **Add necessary test fixtures** in `beforeAll`:88 - Create new entity instances (TableClass, DataProduct, etc.)89 - Set up required relationships (domains, assets)9091 b. **Add cleanup** in `afterAll`:92 - Delete created entities in reverse order9394 c. **Write the test** following the pattern:95 ```typescript96 test('Descriptive Test Name - What it validates', async ({ page }) => {97 test.setTimeout(300000);9899 await test.step('Step description', async () => {100 // Test actions and assertions101 });102103 await test.step('Next step', async () => {104 // More actions and assertions105 });106 });107 ```1081093. **Test patterns to cover:**110 - Happy path (expected behavior)111 - Edge cases (empty states, max values)112 - Error handling (invalid inputs, failed requests)113 - State transitions (before/after actions)114 - UI feedback (loading states, success/error messages)115 - Permissions (disabled buttons, restricted actions)1161174. **Run Playwright lint check:**118 ```bash119 yarn lint:playwright120 ```121 Error-level rules (`no-networkidle`, `no-page-pause`, `no-focused-test`) will block CI. See the handbook's **ESLint Enforcement** section for the full rule reference.122123## Common Test Utilities124125### Navigation126```typescript127import { sidebarClick } from '../../utils/sidebar';128import { redirectToHomePage } from '../../utils/common';129import { selectDataProduct, selectDomain } from '../../utils/domain';130```131132### Waiting133```typescript134import { waitForAllLoadersToDisappear } from '../../utils/entity';135await waitForAllLoadersToDisappear(page);136await expect(page.getByTestId('content')).toBeVisible();137// NEVER use: page.waitForLoadState('networkidle') — blocked by ESLint138```139140### API Responses141```typescript142const response = page.waitForResponse('/api/v1/endpoint*');143await someAction();144await response;145expect((await response).status()).toBe(200);146```147148### Assertions149```typescript150await expect(page.getByTestId('element')).toBeVisible();151await expect(page.getByTestId('element')).toContainText('text');152await expect(page.locator('.class')).not.toBeVisible();153```154155## Checklist Before Completion156157- [ ] All UI changes have corresponding test coverage158- [ ] Tests cover both positive and negative scenarios159- [ ] Tests verify visual indicators (icons, badges, states)160- [ ] Tests validate API interactions161- [ ] `yarn lint:playwright` passes with zero errors162- [ ] No `networkidle`, `page.pause()`, or `test.only()` usage (blocked by ESLint)163- [ ] Test fixtures are properly created and cleaned up164- [ ] Test timeouts use `test.slow()` (preferred) or `test.setTimeout()`165166## Example: Data Contract Inheritance Tests167168For reference, see the comprehensive test coverage in:169`playwright/e2e/Pages/DataContractInheritance.spec.ts`170171This file demonstrates:172- Multiple entity setup in beforeAll173- Domain assignment patches174- Contract creation and validation175- Inheritance icon verification176- Action button state verification (disabled/enabled)177- API response validation (POST vs PATCH)178- Fallback behavior testing179180---181> Converted and distributed by [TomeVault](https://tomevault.io/claim/open-metadata) — claim your Tome and manage your conversions.182<!-- tomevault:4.0:skill_md:2026-04-11 -->