playwright-validation
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
- 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:playwrightError-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
- 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
More from open-metadata/openmetadata
playwright-test
Generate robust, zero-flakiness Playwright E2E tests following OpenMetadata patterns. Creates comprehensive test files with proper waits, API validation, multi-role permissions, and complete entity lifecycle management.
60writing-playwright-tests
Use when writing new Playwright E2E tests or adding test cases. Provides testing philosophy, patterns, and best practices from the Playwright Developer Handbook.
54connector-review
Review an OpenMetadata connector against golden standards. Runs multi-agent analysis covering architecture, code quality, type safety, testing, and performance. When a PR number is given, automatically posts the quality summary to the PR description and a detailed review as a PR comment.
1test-locally
Build and deploy a full local OpenMetadata stack with Docker to test your connector in the UI. Handles code generation, build optimization, health checks, and guided testing.
1connector-standards
Load all OpenMetadata connector development standards into context. Use before building or reviewing connectors to ensure consistent patterns.
1scaffold-connector
Build a new OpenMetadata connector from scratch — scaffold JSON Schema, Python boilerplate, and AI context using schema-first architecture with code generation across Python, Java, TypeScript, and auto-rendered UI forms.
1