Test d'applications Web

Pour tester des applications web locales, écrivez des scripts Playwright Python natifs.

Scripts d'assistance disponibles :

scripts/with_server.py - Gère le cycle de vie du serveur (supporte plusieurs serveurs)

Exécutez toujours les scripts avec --help en premier pour voir l'utilisation. NE LISEZ PAS la source jusqu'à avoir essayé d'exécuter le script en premier et trouvé qu'une solution personnalisée est absolument nécessaire. Ces scripts peuvent être très volumineux et donc consommer votre context window. Ils existent pour être appelés directement comme des scripts black-box plutôt que d'être ingérés dans votre context window.

Déclencheurs

test
testing
playwright
e2e
end to end
integration test
browser test
test web app
automated testing
test suite
qa
quality assurance

Arbre de décision : Choisir votre approche

Tâche utilisateur → Est-ce du HTML statique ?
    ├─ Oui → Lire directement le fichier HTML pour identifier les sélecteurs
    │         ├─ Succès → Écrire un script Playwright en utilisant les sélecteurs
    │         └─ Échoue/Incomplet → Traiter comme dynamique (ci-dessous)
    │
    └─ Non (webapp dynamique) → Le serveur est-il déjà en cours d'exécution ?
        ├─ Non → Exécuter : python scripts/with_server.py --help
        │        Puis utiliser l'assistant et écrire un script Playwright simplifié
        │
        └─ Oui → Reconnaissance puis action :
            1. Naviguer et attendre networkidle
            2. Faire une capture d'écran ou inspecter le DOM
            3. Identifier les sélecteurs à partir de l'état rendu
            4. Exécuter les actions avec les sélecteurs découverts

Exemple : Utiliser with_server.py

Pour démarrer un serveur, exécutez --help en premier, puis utilisez l'assistant :

Serveur unique :

python scripts/with_server.py --server "npm run dev" --port 5173 -- python your_automation.py

Plusieurs serveurs (par ex. 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

Pour créer un script d'automation, incluez uniquement la logique Playwright (les serveurs sont gérés automatiquement) :

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True) # Toujours lancer chromium en mode headless
    page = browser.new_page()
    page.goto('http://localhost:5173') # Serveur déjà en cours d'exécution et prêt
    page.wait_for_load_state('networkidle') # CRITIQUE : Attendre l'exécution de JS
    # ... votre logique d'automation
    browser.close()

Modèle Reconnaissance-puis-Action

Inspecter le DOM rendu :

page.screenshot(path='/tmp/inspect.png', full_page=True)
content = page.content()
page.locator('button').all()

Identifier les sélecteurs à partir des résultats d'inspection
Exécuter les actions avec les sélecteurs découverts

Pièges courants

❌ Ne pas inspecter le DOM avant d'attendre networkidle sur les apps dynamiques ✅ Faire attendre page.wait_for_load_state('networkidle') avant l'inspection

Bonnes pratiques

Utiliser les scripts groupés comme des black boxes - Pour accomplir une tâche, demandez-vous si l'un des scripts disponibles dans scripts/ peut aider. Ces scripts gèrent les workflows courants et complexes de façon fiable sans encombrer le context window. Utilisez --help pour voir l'utilisation, puis invoquez directement.
Utiliser sync_playwright() pour les scripts synchrones
Toujours fermer le navigateur quand vous avez fini
Utiliser des sélecteurs descriptifs : text=, role=, sélecteurs CSS, ou IDs
Ajouter les attentes appropriées : page.wait_for_selector() ou page.wait_for_timeout()

Fichiers de référence

examples/ - Exemples montrant les modèles courants :
- element_discovery.py - Découvrir les boutons, liens et inputs sur une page
- static_html_automation.py - Utiliser les URLs file:// pour le HTML local
- console_logging.py - Capturer les logs de console lors de l'automation

Vérifier

La suite de test a été réellement exécutée et le code de sortie/résultat est capturé dans la transcription, pas seulement écrit
Les comptages de réussite/échec sont rapportés en nombres (par ex. « 42 passés, 0 échoués »), pas « tous les tests passent »
Les nouveaux tests couvrent au moins un cas négatif/limite en plus du cas de succès ; les cas sont énumérés
La delta de couverture ou les modules affectés sont rapportés quand le projet suit la couverture ; un nombre de base est cité
Pour les tests instables ou sensibles au timing, l'exécution a été répétée au moins 3 fois et le taux de réussite est rapporté
Tous les tests ignorés ou xfail introduits sont énumérés avec une raison et un lien issue/TODO

webapp-testing