webapp-testing : tester une appli Web locale avec Playwright

À qui cela s’adresse

Utilisez webapp-testing pour faire interagir Playwright avec une appli Web locale et la tester. Il permet de vérifier le front, déboguer le comportement d’interface, prendre des captures navigateur et lire les journaux navigateur. La cible est une appli locale, pas un balayage de site distant non nommé.

Le cadre le plus adapté : être prêt à écrire des scripts Python Playwright natifs et à gérer le cycle de vie du serveur avec des scripts d’aide. Le matériau source ne donne ni liste de produits d’agents ni installeur ; n’inventez pas un chemin de dépôt. La page officielle de description est

https://raw.githubusercontent.com/anthropics/skills/main/skills/webapp-testing/SKILL.md

Première tentative en 3 minutes

Le premier chemin recommandé est de regarder l’usage des scripts d’aide, pas d’ouvrir le navigateur. Le matériau source nomme scripts/with_server.py pour le cycle de vie du serveur (plusieurs serveurs possibles) et exige : Always run scripts with --help first.

Préalable : l’environnement actuel peut exécuter ce helper. Premier geste à faible risque :

scripts/with_server.py --help

Signal de réussite : l’usage s’affiche et le serveur n’a pas encore été levé. C’est une aide en lecture seule. Ne lisez pas d’abord le source du helper pour deviner les drapeaux — le résumé dit --help d’abord, pas le source d’abord.

Si l’aide est lisible et que vous confirmez tester une appli locale, écrivez alors le script Playwright. Il faut utiliser sync_playwright et démarrer chromium en headless : browser = p.chromium.launch(headless=True). Démarrer le serveur et ouvrir une page changent l’environnement et peuvent écrire des journaux ; confirmez que la cible est votre appli locale avant d’exécuter. Le résumé dit de tester vers localhost après le démarrage du helper, mais l’extrait n’écrit pas de numéro de port ; n’inventez pas d’adresse.

Cas d’usage

Cas 1 : avec le helper et un serveur local, un passage en lecture seule. D’abord --help ; n’appelez scripts/with_server.py qu’après confirmation des paramètres. Dans le script, ouvrez chromium headless avec sync_playwright. Critère de fin : le navigateur a démarré en mode headless et vous n’avez pas encore d’action destructive sur la page. Le matériau source prend en charge captures et lecture de journaux ; ces deux gestes sont relativement réversibles. Avant d’écrire un fichier, confirmez le chemin de dépôt de la capture.

Cas 2 : appli dynamique selon « d’abord reconnaître, puis agir ». Ordre : naviguer et attendre networkidle ; capture ou inspection du DOM ; identifier des sélecteurs depuis le rendu ; puis agir avec les sélecteurs trouvés. Le matériau source dit clairement de ne pas inspecter le DOM sur une appli dynamique avant networkidle ; la bonne voie est d’attendre page.wait_for_load_state('networkidle') puis d’inspecter. Critère de fin : vous pouvez indiquer que l’attente précède l’inspection. Ne cliquez pas un sélecteur non confirmé avant que le réseau soit idle.

Limites d’usage

Couvre uniquement les tests Playwright d’une appli Web locale. chromium toujours headless. Le helper commence par --help. Une appli dynamique doit d’abord networkidle, puis le DOM.

N’inventez ni installeur, ni chemin de dépôt, ni port localhost non écrit. Le matériau source ne donne pas de liste de clients et n’explique pas l’usage sur un site non local. Au-delà de ce helper, de ce démarrage headless et de cet ordre de reconnaissance, ce guide ne couvre pas.