Test d'applications Web

VérifiéPrudence

Boîte à outils pour interagir avec et tester des applications web locales via Playwright. Prend en charge la vérification du frontend, le débogage UI, les captures d'écran et les logs navigateur.

Spar Skills Guide Bot
TestingIntermédiaire
22/07/2026
Claude CodeCursorCodex
#playwright#browser-automation#e2e-testing#web-testing#python

Recommandé pour

Synthèse automatique

Cette skill fournit une boîte à outils Playwright en Python pour piloter et tester des applications web locales, avec un script d'assistance qui gère le cycle de vie des serveurs de développement.

Points forts

  • Script `with_server.py` qui démarre et arrête un ou plusieurs serveurs avant d'exécuter le script Playwright, ce qui évite de gérer manuellement les processus
  • Arbre de décision clair distinguant HTML statique et application dynamique, avec le schéma « reconnaissance puis action »
  • Insistance sur le piège classique : attendre `networkidle` avant d'inspecter le DOM des applications dynamiques
  • Scripts fournis à utiliser comme des boîtes noires via `--help`, ce qui limite la pollution du contexte

Limites

  • Se limite à Playwright en Python : aucun exemple pour d'autres langages ou pour Cypress
  • Suppose que l'environnement dispose déjà de Python et Playwright installés, sans décrire l'installation
  • Ne couvre pas les tests visuels comparatifs, le parallélisme ni l'intégration à une CI
Quand l'utiliser

À utiliser lorsqu'il faut vérifier ou déboguer le comportement d'une application web locale en pilotant un vrai navigateur et en capturant captures d'écran ou logs.

Quand l'éviter

À éviter si vous cherchez à écrire une suite de tests unitaires ou une configuration d'intégration continue complète, car la skill reste centrée sur l'automatisation Playwright ad hoc.

Analyse de sécurité

Prudence
Score qualité86/100

The skill is designed for legitimate local web-app testing with Playwright and does not include destructive, exfiltrating, or obfuscated instructions. However, it directs execution of shell commands, manages local servers, and discourages source inspection of bundled scripts, so it carries meaningful execution risk and should be used only with trusted bundled files.

Points d'attention
  • •Instructs agent to execute local server commands and Playwright automation scripts via bash, which is powerful but appropriate for local web testing.
  • •Advises treating bundled scripts as black boxes and not reading their source unless necessary, reducing auditability if the scripts are not trusted.
  • •The with_server.py helper accepts arbitrary shell commands for --server, which could be abused if command arguments come from untrusted input.
Comment cette analyse est faite

Exemples

Vérifier le flux de connexion
Start my Vite dev server on port 5173 and use Playwright to log in with test@example.com / password123, then screenshot the dashboard.
Déboguer un bouton inactif
My React app on localhost:3000 has a submit button that does nothing. Run it with Playwright, capture console logs, and tell me what's failing.
Inspecter le DOM rendu
Navigate to http://localhost:8000, wait for networkidle, and list all buttons and input selectors on the page so I can write tests against them.

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. 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

  1. Inspect rendered DOM:

    page.screenshot(path='/tmp/inspect.png', full_page=True)
    content = page.content()
    page.locator('button').all()
    
  2. Identify selectors from inspection results

  3. 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 --help to 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() or page.wait_for_timeout()

Reference Files

  • examples/ - Examples showing common patterns:
    • element_discovery.py - Discovering buttons, links, and inputs on a page
    • static_html_automation.py - Using file:// URLs for local HTML
    • console_logging.py - Capturing console logs during automation

Du fichier au premier essai

Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.

Consulter la source et ses fichiers annexes

Ce téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.

1. Télécharger le fichier

Télécharger SKILL.md

Depuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/web-application-testing-mrwakgh4/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.

Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.

mkdir -p '.skill-downloads/web-application-testing-mrwakgh4' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/web-application-testing-mrwakgh4/download' --output '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md.part' && mv '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md.part' '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md'

2. Vérifier les prérequis

Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.

Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.

Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.

3. Charger la skill

Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.

Claude Code
test -f '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md' && test -s '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/webapp-testing' && cp -R '.skill-downloads/web-application-testing-mrwakgh4' '.claude/skills/webapp-testing'

Cursor
test -f '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md' && test -s '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/webapp-testing' && cp -R '.skill-downloads/web-application-testing-mrwakgh4' '.cursor/skills/webapp-testing'

Codex
test -f '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md' && test -s '.skill-downloads/web-application-testing-mrwakgh4/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/webapp-testing' && cp -R '.skill-downloads/web-application-testing-mrwakgh4' '.agents/skills/webapp-testing'

OpenSkills

OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.

Installation officielle d’OpenSkills
openskills install './.skill-downloads/web-application-testing-mrwakgh4'

openskills read 'web-application-testing-mrwakgh4'

La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.

Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.

openskills sync

Mode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.

4. Faire un premier essai

Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :

Lis .skill-downloads/web-application-testing-mrwakgh4/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.

Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.

Skills similaires