Automated summary
Provides a structured approach to test local web applications using Playwright, including server lifecycle management and a reconnaissance-then-action pattern.
Strengths
- Clear decision tree for static vs dynamic web apps
- Handles multi-server setups with lifecycle management
- Promotes reusable black-box scripts to save context
- Includes practical examples and common pitfalls
Limitations
- Requires Playwright and browser dependencies installed locally
- Example scripts may need adaptation for specific projects
- Assumes agent has access to helper scripts in `scripts/` directory
Use when you need to automate or test a local web application's UI, especially dynamic apps with JavaScript.
Do not use for static HTML files that can be read directly, or for non-browser-based applications.
Security analysis
SafeThe skill provides instructions for writing and running Playwright tests locally, using helper scripts for server management. No destructive, exfiltrating, or obfuscated actions are present. All commands are standard testing operations.
No concerns found
How this analysis is madeExamples
I need to test the login flow on my local web app running on port 5173. Please use Playwright to open the page, fill in username and password fields with 'admin' and 'password123', click the login button, and verify that the dashboard page loads successfully.Take a full-page screenshot of my local app at http://localhost:3000 after it finishes loading. Save the screenshot to /tmp/dashboard.png and describe any UI elements you find.Inspect my dynamic web app at http://localhost:5173 for console errors. Navigate through the main pages (home, about, contact) and capture any console logs (warnings/errors) along with screenshots of each page.name: webapp-testing description: Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs. Includes 149 tests e2e pour Construction Gauthier / Ma Place RH. license: Complete terms in LICENSE.txt
Web Application Testing
To test local web applications, write native Python Playwright scripts.
Helper Scripts Available:
scripts/with_server.py- Manages server lifecycle (supports multiple servers)
Always run scripts with --help first to see usage. DO NOT read the source until you try running the script first and find that a customized solution is abslutely necessary. These scripts can be very large and thus pollute your context window. They exist to be called directly as black-box scripts rather than ingested into your context window.
Decision Tree: Choosing Your Approach
User task → Is it static HTML?
├─ Yes → Read HTML file directly to identify selectors
│ ├─ Success → Write Playwright script using selectors
│ └─ Fails/Incomplete → Treat as dynamic (below)
│
└─ No (dynamic webapp) → Is the server already running?
├─ No → Run: python scripts/with_server.py --help
│ Then use the helper + write simplified Playwright script
│
└─ Yes → Reconnaissance-then-action:
1. Navigate and wait for networkidle
2. Take screenshot or inspect DOM
3. Identify selectors from rendered state
4. Execute actions with discovered selectors
Example: Using with_server.py
To start a server, run --help first, then use the helper:
Single server:
python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py
Multiple servers (e.g., backend + frontend):
python scripts/with_server.py \
--server "cd backend && python server.py" --port 3000 \
--server "cd frontend && npm run dev" --port 5173 \
-- python your_automation.py
To create an automation script, include only Playwright logic (servers are managed automatically):
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
browser = p.chromium.launch(headless=True) # Always launch chromium in headless mode
page = browser.new_page()
page.goto('http://localhost:5173') # Server already running and ready
page.wait_for_load_state('networkidle') # CRITICAL: Wait for JS to execute
# ... your automation logic
browser.close()
Reconnaissance-Then-Action Pattern
-
Inspect rendered DOM:
page.screenshot(path='/tmp/inspect.png', full_page=True) content = page.content() page.locator('button').all() -
Identify selectors from inspection results
-
Execute actions using discovered selectors
Common Pitfall
❌ Don't inspect the DOM before waiting for networkidle on dynamic apps
✅ Do wait for page.wait_for_load_state('networkidle') before inspection
Best Practices
- Use bundled scripts as black boxes - To accomplish a task, consider whether one of the scripts available in
scripts/can help. These scripts handle common, complex workflows reliably without cluttering the context window. Use--helpto see usage, then invoke directly. - Use
sync_playwright()for synchronous scripts - Always close the browser when done
- Use descriptive selectors:
text=,role=, CSS selectors, or IDs - Add appropriate waits:
page.wait_for_selector()orpage.wait_for_timeout()
Reference Files
- examples/ - Examples showing common patterns:
element_discovery.py- Discovering buttons, links, and inputs on a pagestatic_html_automation.py- Using file:// URLs for local HTMLconsole_logging.py- Capturing console logs during automation
Construction Gauthier - Tests E2E Playwright
Le projet Construction Gauthier dispose d'une suite complète de tests Playwright TypeScript (149 tests).
Commandes d'exécution
# Tous les tests (149 tests, ~1 min)
npx playwright test
# Tests par projet
npx playwright test --project=chromium # Tests auth généraux (15)
npx playwright test --project=ma-place-rh # Tests Ma Place RH (99)
npx playwright test --project=ma-place-rh:security # Tests permissions (18)
npx playwright test --project=ma-place-rh:workflows # Tests workflows (17)
# Tests par fonctionnalité
npx playwright test specs/features/evaluations.spec.ts
npx playwright test specs/features/surveys.spec.ts
npx playwright test specs/leave/
# Mode debug avec UI
npx playwright test --ui
# Voir le rapport HTML
npx playwright show-report
Structure des tests Ma Place RH
modules/ma-place-rh/tests/e2e/
├── fixtures/
│ ├── auth.fixture.ts # Multi-contextes (employeePage, managerPage, directorPage)
│ └── index.ts
├── utils/
│ └── test-users.ts # Utilisateurs fictifs de test
├── page-objects/
│ ├── base.page.ts
│ ├── employee/leave-request.page.ts
│ └── manager/approvals.page.ts
├── workflows/
│ └── leave-request.workflow.ts
└── specs/
├── auth/permissions.spec.ts # 18 tests permissions/sécurité
├── leave/full-workflow.spec.ts # 17 tests congés
└── features/
├── dashboards.spec.ts # 10 tests
├── evaluations.spec.ts # 7 tests
├── surveys.spec.ts # 6 tests
├── team.spec.ts # 6 tests
├── performance.spec.ts # 6 tests
├── competences.spec.ts # 5 tests
├── documents.spec.ts # 5 tests
├── onboarding.spec.ts # 5 tests
├── 2x4-news.spec.ts # 4 tests
├── events.spec.ts # 4 tests
├── roles-permissions.spec.ts # 4 tests
└── reports.spec.ts # 4 tests
Utilisateurs de test
Les tests utilisent des utilisateurs fictifs via le mode VITE_AUTH_BYPASS=true:
| Rôle | ID | Email | |------|-----|-------| | Admin | 11111111-... | admin@constructiongauthier.local | | Directeur | 22222222-... | cto@constructiongauthier.local | | Manager | 33333333-... | gestionnaire.rh@constructiongauthier.local | | Employé | 44444444-... | employe@constructiongauthier.local |
Ajouter un nouveau test
- Créer le fichier dans
specs/features/ouspecs/[feature]/ - Importer les fixtures:
import { test, expect } from '../../fixtures'; - Utiliser les pages pré-authentifiées:
employeePage,managerPage,directorPage
import { test, expect } from '../../fixtures';
test.describe('Ma Feature', () => {
test('Employé peut accéder à la feature', async ({ employeePage }) => {
await employeePage.goto('/ma-place-rh/ma-feature');
await employeePage.waitForLoadState('networkidle');
await expect(employeePage.locator('h1')).toContainText('Ma Feature');
});
test('Employé ne peut pas accéder à la vue manager', async ({ employeePage }) => {
await employeePage.goto('/ma-place-rh/manager/ma-feature');
await employeePage.waitForLoadState('networkidle');
expect(employeePage.url()).not.toContain('/manager/ma-feature');
});
});
Prérequis
- L'app doit tourner sur
http://localhost:5173avecVITE_AUTH_BYPASS=true - Ou laisser Playwright démarrer le serveur automatiquement (configuré dans
playwright.config.ts)
From the file to a first result
The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.
View the source and supporting filesThis download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.
1. Download the file
Download SKILL.mdFrom the root of a test project, save the file as .skill-downloads/web-application-testing-mmbizj2b/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.
Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.
mkdir -p '.skill-downloads/web-application-testing-mmbizj2b' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/web-application-testing-mmbizj2b/download' --output '.skill-downloads/web-application-testing-mmbizj2b/SKILL.md.part' && mv '.skill-downloads/web-application-testing-mmbizj2b/SKILL.md.part' '.skill-downloads/web-application-testing-mmbizj2b/SKILL.md'2. Check prerequisites
Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.
Original excerpt: Prérequis
- L'app doit tourner sur
http://localhost:5173avecVITE_AUTH_BYPASS=true - Ou laisser Playwright démarrer le serveur automatiquement (configuré dans
playwright.config.ts)
The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.
3. Load the skill
After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.
Claude Code
test -f '.skill-downloads/web-application-testing-mmbizj2b/SKILL.md' && test -s '.skill-downloads/web-application-testing-mmbizj2b/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/webapp-testing' && cp -R '.skill-downloads/web-application-testing-mmbizj2b' '.claude/skills/webapp-testing'OpenSkills
OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.
Official OpenSkills installationopenskills install './.skill-downloads/web-application-testing-mmbizj2b'openskills read 'web-application-testing-mmbizj2b'Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.
For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.
openskills syncManual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.
4. Try a first task
Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:
Read .skill-downloads/web-application-testing-mmbizj2b/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.
ClickHouse Performance Comparison
Testing
Evaluate ClickHouse performance test results, check PR performance changes, compare with history, and assess whether a result is actionable.
Analyze CI Performance Reports
Testing
Analyze CI performance comparison reports for a ClickHouse PR. Cross-references master history to distinguish real regressions from flaky tests.
Santa Method
Testing
Multi-agent adversarial verification with two independent reviewers. Output is checked twice and iteratively fixed until both pass before shipping.