playwright-validation

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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:**
   ```bash
   git diff main --stat
   git diff main --name-only | grep -E "\.(tsx?|less|css|scss)$"
   ```

2. **Focus on UI component changes:**
   ```bash
   git diff main -- "openmetadata-ui/src/main/resources/ui/src/components/**" --stat
   ```

3. **Check for existing Playwright tests:**
   ```bash
   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:
      ```typescript
      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:**
   ```bash
   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

From open-metadata/OpenMetadata, Apache-2.0.

More from open-metadata/OpenMetadata