agentleFS
CODE-SAURABHCODE-SAURABH/OpenSkills/webapp-testing/SKILL.md

webapp-testing

Skill2 starsChanged 4 months agoMITView on GitHub

Automated end-to-end web application testing using Playwright. Use when the user wants to write automated tests for a web app, test frontend functionality, verify UI behaviour programmatically, debug interactions in a browser, capture screenshots of a running app, check for console errors, or test a user flow from login to completion.

  • Reads credentials
  • Installs packages

196 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use academy-guide, skill-share and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • AnthropicSkill

    academy-guide

    Stop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: "how do I", "how can I", "getting started with", "what can Claude do", "teach me", "learn to use"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.

    Also in 8 projects that use this

  • ArogyaReddySkill

    skill-share

    A skill that creates new Claude skills and automatically shares them on Slack using Rube for seamless team collaboration and skill discovery.

    Also in 23 projects that use this

  • SKB3002Skill

    intelligent-routing

    Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.

    Also in 5 projects that use this

  • ArogyaReddySkill

    raffle-winner-picker

    Picks random winners from lists, spreadsheets, or Google Sheets for giveaways, raffles, and contests. Ensures fair, unbiased selection with transparency.

    Also in 26 projects that use this

  • zephyrwang6Skill

    topic-collector

    AI热点采集工具。从Twitter/X、Product Hunt、Reddit、Hacker News、博客等采集AI相关热点内容。当用户说"开始今日选题"、"采集热点"、"看看今天有什么新闻"、"今日AI热点"时触发。聚焦领域:Vibe Coding、Claude Skill、AI知识管理、AI模型更新、AI新产品、海外热点。

    Also in 4 projects that use this

  • zephyrwang6Skill

    deepl

    Übersetzt Texte, Dokumente und XLIFF-Dateien via DeepL API. Verwende für Übersetzungen mit /deepl translate, /deepl file oder /deepl xliff.

    Also in 4 projects that use this

  • +4 more from zephyrwang6
  • +1 more from ArogyaReddy

The file

We split this skill into the rules it gives an agent

5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 190 edited versions we read keep these.

  • 5

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Reconnaissance before action: Never assume a selector exists.

    line 14
  2. Distinctive:

    Test what the user experiences: Test by role, text, and label — not by CSS class or XPath.

    line 16
  3. Distinctive:

    Screenshot on failure: Every test should capture a screenshot when it fails — this is the single fastest debugging tool available.

    line 19
  4. Distinctive:

    Before writing any selectors, discover the actual rendered DOM:

    line 78
  5. Distinctive:

    Run this first. Read the output.

    line 103

“Common” is measured: kept by at least 6 in 10 of the 190 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Web App Testing (Playwright)

Manual testing finds bugs once. Automated tests find them every time. This skill writes Playwright scripts that test real browser behaviour — clicks, forms, navigation, network calls, and visual state — reliably and repeatably.


Web App Testing Principles

  • Reconnaissance before action. Never assume a selector exists. Navigate, wait for load, inspect the DOM, then act. Selectors that work in dev break in staging. Discover them at runtime.
  • Wait for real readiness. networkidle is not always enough. Wait for the specific element you need, not just page load.
  • Test what the user experiences. Test by role, text, and label — not by CSS class or XPath. Classes change; user-facing text is more stable.
  • One test, one user journey. A test that does login + checkout + confirmation + email verification is four tests jammed together. Split them.
  • Tests must clean up after themselves. A test that leaves state (created users, placed orders) that affects the next test is a flaky test waiting to happen.
  • Screenshot on failure. Every test should capture a screenshot when it fails — this is the single fastest debugging tool available.

Step 0: Choose the Right Approach

Is the app running?
├── NO → Start it first with with_server.py helper (if available)
│         or: npm run dev / python app.py in background
└── YES
    └── Is it static HTML (no JS framework)?
        ├── YES → Read HTML directly, write selectors from source
        └── NO (React, Vue, Svelte, etc.)
            → Reconnaissance first: navigate → networkidle → screenshot → inspect → act

Project Setup

Install Playwright

npm init -y
npm install -D @playwright/test
npx playwright install chromium  # or: install firefox, webkit too

# Python
pip install playwright
playwright install chromium

Config (playwright.config.ts)

import { defineConfig } from "@playwright/test";

export default defineConfig({
  testDir: "./tests",
  timeout: 30_000,
  retries: process.env.CI ? 2 : 0,  // retry in CI, not locally
  use: {
    baseURL: process.env.BASE_URL ?? "http://localhost:3000",
    headless: true,
    screenshot: "only-on-failure",  // always capture on failure
    video: "retain-on-failure",
    trace: "retain-on-failure",
  },
  webServer: {
    command: "npm run dev",
    port: 3000,
    reuseExistingServer: !process.env.CI,
  },
});

Reconnaissance Pattern (Always Do This First)

Before writing any selectors, discover the actual rendered DOM:

import { test, expect } from "@playwright/test";

test("reconnaissance — inspect login page", async ({ page }) => {
  await page.goto("/login");
  await page.waitForLoadState("networkidle");

  // Take screenshot to see what's there
  await page.screenshot({ path: "screenshots/login.png", fullPage: true });

  // List all interactive elements
  const buttons = await page.locator("button").all();
  for (const btn of buttons) {
    console.log("Button:", await btn.textContent(), await btn.getAttribute("type"));
  }

  const inputs = await page.locator("input").all();
  for (const input of inputs) {
    console.log("Input:", await input.getAttribute("name"), await input.getAttribute("type"));
  }
});

Run this first. Read the output. Then write your real tests based on what actually exists.


Writing Tests

Preferred Selector Order (most stable → least stable)

// 1. Role + name (most resilient — matches what users see)
page.getByRole("button", { name: "Sign in" })
page.getByRole("textbox", { name: "Email address" })
page.getByRole("link", { name: "Forgot password?" })

// 2. Label (for form fields)
page.getByLabel("Email address")
page.getByLabel("Password")

// 3. Test ID (when team adds them explicitly)
page.getByTestId("submit-button")

// 4. Text (for non-interactive elements)
page.getByText("Welcome back")

// 5. CSS selector (last resort — fragile, breaks on refactor)
page.locator(".login-form button[type='submit']")

// ❌ Never use XPath — brittle, unreadable
page.locator("//button[@class='btn-primary']")

Complete Login Test

import { test, expect } from "@playwright/test";

test.describe("Authentication", () => {
  test("user can log in with valid credentials", async ({ page }) => {
    await page.goto("/login");
    await page.waitForLoadState("networkidle");

    // Fill form
    await page.getByLabel("Email").fill("test@example.com");
    await page.getByLabel("Password").fill("password123");

    // Submit
    await page.getByRole("button", { name: "Sign in" }).click();

    // Verify redirect to dashboard
    await page.waitForURL("**/dashboard");
    await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
  });

  test("shows error on invalid credentials", async ({ page }) => {
    await page.goto("/login");
    await page.getByLabel("Email").fill("wrong@example.com");
    await page.getByLabel("Password").fill("wrongpassword");
    await page.getByRole("button", { name: "Sign in" }).click();

    await expect(page.getByText("Invalid email or password")).toBeVisible();
    // Should NOT redirect
    await expect(page).toHaveURL(/.*login.*/);
  });
});

Form Submission Test

test("user can submit contact form", async ({ page }) => {
  await page.goto("/contact");
  await page.waitForLoadState("networkidle");

  await page.getByLabel("Name").fill("Jane Doe");
  await page.getByLabel("Email").fill("jane@example.com");
  await page.getByLabel("Message").fill("This is a test message with sufficient length.");

  // Intercept the API call to verify it's made
  const responsePromise = page.waitForResponse(
    response => response.url().includes("/api/contact") && response.status() === 200
  );

  await page.getByRole("button", { name: "Send message" }).click();

  await responsePromise;
  await expect(page.getByText("Message sent successfully")).toBeVisible();
});

Navigation Test

test("main navigation links work", async ({ page }) => {
  await page.goto("/");
  await page.waitForLoadState("networkidle");

  const navItems = [
    { link: "Products", url: /.*products.*/ },
    { link: "Pricing",  url: /.*pricing.*/ },
    { link: "About",    url: /.*about.*/  },
  ];

  for (const { link, url } of navItems) {
    await page.getByRole("navigation").getByRole("link", { name: link }).click();
    await expect(page).toHaveURL(url);
    await page.goBack();
    await page.waitForLoadState("networkidle");
  }
});

API Interception

test("handles API failure gracefully", async ({ page }) => {
  // Mock the API to return an error
  await page.route("**/api/users", route => {
    route.fulfill({ status: 500, body: JSON.stringify({ error: "Server error" }) });
  });

  await page.goto("/users");
  await page.waitForLoadState("networkidle");

  // App should show error state, not crash
  await expect(page.getByText("Something went wrong")).toBeVisible();
  await expect(page.getByRole("button", { name: "Try again" })).toBeVisible();
});

Visual Testing

Screenshot comparison

test("dashboard looks correct", async ({ page }) => {
  await page.goto("/dashboard");
  await page.waitForLoadState("networkidle");

  // Wait for data to load before snapping
  await page.waitForSelector("[data-testid='chart']");

  await expect(page).toHaveScreenshot("dashboard.png", {
    maxDiffPixelRatio: 0.02  // allow 2% pixel difference
  });
});

Console error detection

test("page has no console errors", async ({ page }) => {
  const errors: string[] = [];

  page.on("console", msg => {
    if (msg.type() === "error") errors.push(msg.text());
  });

  page.on("pageerror", err => errors.push(err.message));

  await page.goto("/");
  await page.waitForLoadState("networkidle");

  expect(errors).toHaveLength(0);
});

Python Playwright

import pytest
from playwright.sync_api import Page, expect

def test_login(page: Page):
    page.goto("/login")
    page.wait_for_load_state("networkidle")

    page.get_by_label("Email").fill("test@example.com")
    page.get_by_label("Password").fill("password123")
    page.get_by_role("button", name="Sign in").click()

    page.wait_for_url("**/dashboard")
    expect(page.get_by_role("heading", name="Dashboard")).to_be_visible()

def test_shows_error_on_invalid_login(page: Page):
    page.goto("/login")
    page.get_by_label("Email").fill("wrong@example.com")
    page.get_by_label("Password").fill("wrong")
    page.get_by_role("button", name="Sign in").click()

    expect(page.get_by_text("Invalid email or password")).to_be_visible()
# Run
pytest tests/ -v

# With headed browser (see what's happening)
pytest tests/ --headed

# Generate HTML report
pytest tests/ --html=report.html

Debugging Failures

// Slow down execution to watch what's happening
test.use({ actionTimeout: 5000 });

// Pause and inspect in headed mode
await page.pause();  // opens Playwright Inspector

// Log every network request
page.on("request", req => console.log("→", req.method(), req.url()));
page.on("response", res => console.log("←", res.status(), res.url()));

// Dump current DOM
const html = await page.content();
console.log(html.slice(0, 2000));

// Check what Playwright sees
await page.screenshot({ path: "debug.png", fullPage: true });

CI Integration

# .github/workflows/e2e.yml
name: E2E Tests
on: [push, pull_request]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npx playwright test
        env:
          BASE_URL: http://localhost:3000
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-report
          path: playwright-report/

Common Pitfalls

MistakeWhy it failsFix
Not waiting for networkidle on dynamic appsJS hasn't hydrated yet — selectors not foundawait page.waitForLoadState("networkidle")
Hardcoding CSS classes as selectorsClasses change on refactorUse getByRole, getByLabel, getByText
Not closing browser on errorOrphaned browser processesUse test.afterEach cleanup or using
page.click() before element is visibleRace conditionawait page.getByRole(...).click() waits automatically
Writing one giant testFlaky, hard to debug, slow to isolateOne test per user journey
No screenshot on failureCan't debug without knowing what was on screenSet screenshot: "only-on-failure" in config

Definition of Done — Web App Testing

  • Reconnaissance run first — selectors discovered from rendered DOM
  • getByRole, getByLabel, or getByText used — no raw CSS selectors
  • Each test covers exactly one user journey
  • waitForLoadState("networkidle") called after navigation
  • Screenshot on failure configured in playwright.config.ts
  • Both happy path and error paths tested
  • API mocking tested for failure states
  • Tests are independent — no shared mutable state between tests
  • Tests clean up after themselves (created data removed in afterEach)
  • CI pipeline runs tests on every PR
  • Failure artifacts (screenshots, traces) uploaded in CI

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.