MCPInstall

webapp-testing

Use when the user needs Playwright-based web application testing — screenshots, browser log analysis, interaction verification, visual regression, accessibility, and network mocking. Triggers: E2E test setup, visual regression testing, accessibility audit, Playwright configuration, page object model creation, CI test pipeline.

Installs
80
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/pixel-process-ug/superkit-agents --skill webapp-testing
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads webapp-testing automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

Web App Testing

Overview

Comprehensive web application testing using Playwright as the primary tool. This skill covers end-to-end testing workflows including screenshot capture for visual verification, browser console log analysis, user interaction simulation, visual regression testing, accessibility auditing with axe-core, network request mocking, and mobile viewport testing.

Announce at start: "I'm using the webapp-testing skill for Playwright-based web application testing."


Phase 1: Test Planning

Goal: Identify what to test and set up the infrastructure.

Actions

  1. Identify critical user flows to test
  2. Define test environments and viewports
  3. Set up test fixtures and data
  4. Configure Playwright project settings
  5. Establish visual baseline screenshots

User Flow Priority Decision Table

Flow TypePriorityTest Depth
Authentication (login/logout/register)CriticalFull happy + error paths
Core business workflow (purchase, submit)CriticalFull happy + error + edge cases
Navigation and routingHighAll major routes
Search and filteringHighCommon queries + empty state
Settings and profileMediumHappy path
Admin/back-officeMediumKey operations only

STOP — Do NOT proceed to Phase 2 until:

  • Critical user flows are identified and prioritized
  • Test environments and viewports are defined
  • Playwright config is ready
  • Test data strategy is defined

Phase 2: Test Implementation

Goal: Write tests using page object models and accessible locators.

Actions

  1. Write page object models for key pages
  2. Implement end-to-end test scenarios
  3. Add visual regression snapshots
  4. Integrate accessibility checks
  5. Configure network mocking for isolated tests

Playwright Configuration

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests/e2e',
  fullyParallel: true,
  forbidOnly: !!process.env.CI,
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: [
    ['html', { open: 'never' }],
    ['junit', { outputFile: 'test-results/junit.xml' }],
  ],
  use: {
    baseURL: 'http://localhost:3000',
    trace: 'on-first-retry',
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
  },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'mobile-chrome', use: { ...devices['Pixel 5'] } },
    { name: 'mobile-safari', use: { ...devices['iPhone 13'] } },
  ],
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: !process.env.CI,
  },
});

Page Object Model

class LoginPage {
  constructor(private page: Page) {}

  readonly emailInput = this.page.getByLabel('Email');
  readonly passwordInput = this.page.getByLabel('Password');
  readonly submitButton = this.page.getByRole('button', { name: 'Sign in' });
  readonly errorMessage = this.page.getByRole('alert');

  async login(email: string, password: string) {
    await this.emailInput.fill(email);
    await this.passwordInput.fill(password);
    await this.submitButton.click();
  }

  async expectError(message: string) {
    await expect(this.errorMessage).toContainText(message);
  }
}

Locator Selection Decision Table

Locator TypePriorityWhen to Use
getByRole1st choiceAny element with ARIA role (button, link, heading)
getByLabel2nd choiceForm fields with labels
getByPlaceholder3rd choiceFields without visible labels
getByText4th choiceNon-interactive visible text
getByTestIdLast resortWhen no accessible locator works
CSS selector / XPathNeverBreaks with styling changes

STOP — Do NOT proceed to Phase 3 until:

  • Page object models exist for key pages
  • Tests use accessible locators exclusively
  • Visual baselines are established
  • Accessibility checks are integrated
  • Network mocking is configured for isolated tests

Phase 3: CI Integration

Goal: Configure reliable, fast test execution in CI.

Actions

  1. Configure headless browser execution
  2. Set up screenshot artifact collection
  3. Configure retry and flake detection
  4. Add reporting (HTML report, JUnit XML)
  5. Set up visual diff review process

CI Configuration Checklist

  • Tests run headless in CI
  • Retries enabled (2 retries for CI)
  • Screenshot and video artifacts collected on failure
  • JUnit XML output for CI integration
  • HTML report generated for manual review
  • Visual diff snapshots reviewed before merge

STOP — CI integration complete when:

  • Tests run reliably in CI pipeline
  • Artifacts are collected on failure
  • Flaky tests are identified and fixed (not skipped)

Screenshot Capture Patterns

Full Page

test('homepage renders correctly', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveScreenshot('homepage.png', {
    fullPage: true,
    maxDiffPixelRatio: 0.01,
  });
});

Element-Level

test('navigation bar matches design', async ({ page }) => {
  await page.goto('/');
  const nav = page.getByRole('navigation');
  await expect(nav).toHaveScreenshot('navbar.png');
});

Dynamic Content Masking

test('dashboard layout', async ({ page }) => {
  await page.goto('/dashboard');
  await expect(page).toHaveScreenshot('dashboard.png', {
    mask: [
      page.locator('[data-testid="timestamp"]'),
      page.locator('[data-testid="user-avatar"]'),
      page.locator('.chart-container'),
    ],
    animations: 'disabled',
  });
});

Browser Log Analysis

test('no console errors on page load', async ({ page }) => {
  const consoleErrors: string[] = [];

  page.on('console', msg => {
    if (msg.type() === 'error') consoleErrors.push(msg.text());
  });
  page.on('pageerror', error => {
    consoleErrors.push(error.message);
  });

  await page.goto('/');
  await page.waitForLoadState('networkidle');
  expect(consoleErrors).toEqual([]);
});

Accessibility Testing with axe-core

import AxeBuilder from '@axe-core/playwright';

test('page has no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
    .exclude('.third-party-widget')
    .analyze();
  expect(results.violations).toEqual([]);
});

Network Request Mocking

test('displays users from API', async ({ page }) => {
  await page.route('**/api/users', async route => {
    await route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify([{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }]),
    });
  });
  await page.goto('/users');
  await expect(page.getByText('Alice')).toBeVisible();
});

test('handles API errors gracefully', async ({ page }) => {
  await page.route('**/api/users', route =>
    route.fulfill({ status: 500, body: 'Internal Server Error' })
  );
  await page.goto('/users');
  await expect(page.getByText('Something went wrong')).toBeVisible();
});

Mobile Viewport Testing

test.describe('mobile responsive', () => {
  test.use({ viewport: { width: 375, height: 667 } });

  test('hamburger menu works', async ({ page }) => {
    await page.goto('/');
    await expect(page.getByRole('navigation')).not.toBeVisible();
    await page.getByRole('button', { name: 'Menu' }).click();
    await expect(page.getByRole('navigation')).toBeVisible();
  });
});

Test Organization

tests/
  e2e/
    auth/
      login.spec.ts
      register.spec.ts
    checkout/
      cart.spec.ts
      payment.spec.ts
    fixtures/
      test-data.ts
      auth.setup.ts
    pages/
      login.page.ts
      dashboard.page.ts
    utils/
      helpers.ts

Anti-Patterns / Common Mistakes

Anti-PatternWhy It Is WrongCorrect Approach
CSS selectors or XPathBreak with styling changesUse accessible locators (role, label, text)
page.waitForTimeout()Arbitrary delays, flakyUse expect().toBeVisible() or similar
Testing third-party components in detailNot your code to testTest your integration, not their internals
Hardcoded test dataBreaks across environmentsUse fixtures and factories
Tests depending on execution orderFragile, hard to debugEach test must be independent
Ignoring flaky testsErodes trust in test suiteFix root cause or quarantine
Screenshots without masking dynamic contentAlways different, always failingMask timestamps, avatars, charts
No accessibility checksMissing critical quality gateaxe-core on every page

Integration Points

SkillRelationship
senior-frontendFrontend components are tested by E2E tests
testing-strategyE2E tests are the top of the testing pyramid
acceptance-testingUser flow tests serve as acceptance tests
performance-optimizationPerformance budgets can be verified in E2E
code-reviewReview checks that tests use accessible locators
security-reviewSecurity headers and auth flows tested in E2E

Quality Checklist

  • All critical user flows covered
  • Tests use accessible locators (role, label, text)
  • Network mocking for isolated tests
  • Visual regression baselines reviewed and approved
  • Accessibility scans on all pages
  • Mobile viewport tests for responsive features
  • No waitForTimeout (use proper assertions)
  • CI pipeline configured with retries
  • Screenshot artifacts collected on failure
  • Flaky tests identified and fixed (not skipped)

Skill Type

FLEXIBLE — Adapt test depth to the project's critical paths. The page object model pattern and accessible locators are strongly recommended. Accessibility checks are mandatory on every page. Visual regression baselines must be reviewed before merge.

FAQ

What does the webapp-testing skill do?

Use when the user needs Playwright-based web application testing — screenshots, browser log analysis, interaction verification, visual regression, accessibility, and network mocking. Triggers: E2E test setup, visual regression testing, accessibility audit, Playwright configuration, page object model creation, CI test pipeline.

How do I install webapp-testing?

Run npx skills add https://github.com/pixel-process-ug/superkit-agents --skill webapp-testing in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/webapp-testing/ (personal) or .claude/skills/webapp-testing/ (project).

Which AI agents can use webapp-testing?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is webapp-testing safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains webapp-testing?

It is published by pixel-process-ug in pixel-process-ug/superkit-agents. It has 80 recorded installs.

More from pixel-process-ug/superkit-agents

View all →

ui-ux-pro-max

pixel-process-ug/superkit-agents

Use when the user needs full UI/UX design intelligence — styles, palettes, fonts, UX guidelines, chart selection, and accessible, performant implementation across any supported stack. Triggers: user says "design", "UI", "UX", "color palette", "typography", "accessibility", "responsive design", "chart type", "style guide", building any user-facing interface.

Frontend & Design1.2K installs

frontend-ui-design

pixel-process-ug/superkit-agents

Open the skill to read its SKILL.md instructions.

Frontend & Design117 installs

reverse-engineering-specs

pixel-process-ug/superkit-agents

Open the skill to read its SKILL.md instructions.

107 installs

canvas-design

pixel-process-ug/superkit-agents

Open the skill to read its SKILL.md instructions.

90 installs

autonomous-loop

pixel-process-ug/superkit-agents

Open the skill to read its SKILL.md instructions.

88 installs

mobile-design

pixel-process-ug/superkit-agents

Open the skill to read its SKILL.md instructions.

Mobile87 installs

Popular testing & qa skills

View category →

tdd

mattpocock/skills

Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

Testing & QA1.2M installs

grilling

mattpocock/skills

Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.

Testing & QA996.2K installs

migrate-to-shoehorn

mattpocock/skills

Migrate test files from as type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace as in tests, or needs partial test data.

Testing & QA484.1K installs

run-train

lllllllama/rigorpilot-skills

Rigor Train skill for deep learning research repositories. Use when a documented or selected training command should be run conservatively for startup verification, short-run verification, full kickoff, or resume, with command, config, seed, log, checkpoint, status, and metric evidence written to standardized trainoutputs/. Do not use for environment setup, exploratory sweeps, speculative idea implementation, or end-to-end orchestration.

Testing & QA337.8K installs

test-driven-development

obra/superpowers

Use when implementing any feature or bugfix, before writing implementation code

Testing & QA261.8K installs

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work

Testing & QA216.8K installs