Trace Viewer Playwright pour déboguer des tests autorisés
Capturez les traces Playwright pour diagnostiquer des tests reproductibles tout en limitant leur contenu, leur conservation et leur partage.
Vous voulez la documentation structurée pour Démarrage ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Contenu d'une trace Playwright
Le tracing Playwright enregistre une chronologie pour un test autorisé afin d'examiner un échec. Trace Viewer peut afficher actions, réseau, console, captures et instantanés selon les options. La trace décrit ce que le navigateur a observé ; elle ne prouve pas l'acceptation d'une requête par un service.
La documentation Trace Viewer explique l'ouverture d'une trace et le guide des bonnes pratiques recommande des tests isolés. Cherchez la première action ou assertion qui s'écarte du contrat attendu.
Une trace peut contenir du texte, des libellés, des URL ou des en-têtes sensibles. Capturez uniquement un scénario synthétique ou approuvé ; n'ajoutez pas de session réelle, de paiement ou de jeton.
Consultez le cycle de vie BrowserContext et le modèle de stockage. L'isolation ne rédige pas une trace déjà créée.
Capture limitée
Activez le tracing dans le plus petit fixture nécessaire et arrêtez-le dans finally. Conservez généralement la première nouvelle tentative et vérifiez la référence API actuelle.
await context.tracing.start({ screenshots: true, snapshots: true, sources: false });
try {
await runAuthorizedScenario(page);
} finally {
await context.tracing.stop({ path: tracePath });
}
Utilisez un chemin par worker et signalez une archive absente ou partielle comme problème d'infrastructure. La trace doit répondre à une question précise.
Chaque nouvelle tentative crée un contexte neuf avec les mêmes entrées synthétiques autorisées. Ne réutilisez pas un état inconnu.
Revue, retrait et conservation
Ouvrez la trace localement ou dans le système approuvé. Commencez par la chronologie et l'assertion, puis examinez réseau ou instantané seulement pour classer l'échec.
Retirez les jetons, cookies, noms, paiements, URL privées et contenus clients avant le partage. Si la réduction est impossible, gardez la trace restreinte et partagez le diagnostic.
Adaptez la conservation au besoin et faites expirer l'archive après reproduction. context.close() ne supprime pas une copie envoyée à CI.
Procédure et limites
Définissez le contrat visible avant la lecture. Notez scénario, versions, résultat et nettoyage ; hors de la limite du navigateur, demandez le diagnostic pris en charge par le service.
Utilisez artifacts/traces/<test>-<worker>-<attempt>.zip et publiez seulement les métadonnées nécessaires. Indiquez une trace manquante, corrompue ou prise après teardown.
BotBrowser peut fournir un contexte isolé et un profil reproductible pour un flux Playwright autorisé. Il ne garantit pas l'absence de contenu sensible, ne retire pas les jetons des instantanés et ne rend pas une panne de service observable ; l'équipe choisit les entrées synthétiques et applique l'accès et la conservation. Voir la documentation d'isolation multi-comptes.
Identifiez le test.
Nommez le scénario synthétique.
Notez les versions.
Indiquez la première divergence.
Classez le résultat.
Indiquez les captures.
Indiquez les données réseau.
Réservez un chemin privé par worker.
Arrêtez le tracing avant le déplacement.
Gardez les secrets hors de CI.
Créez un contexte par tentative.
N'utilisez pas d'état inconnu.
Ne minimisez pas le premier échec.
Préférez une condition visible.
Activez les captures si nécessaire.
Réduisez une archive trop grande.
Limitez les lecteurs.
Fixez une expiration.
Vérifiez avant le partage.
Séparez les preuves navigateur et service.
Le propriétaire confirme le serveur.
Consignez les erreurs de nettoyage.
Réévaluez après un changement de flux.
Reproduisez dans un dossier propre.
Nettoyez seulement les fichiers du test.
Rendez le nettoyage répétable.
Faites expirer les copies.
Revoyez les champs sensibles.
Le registre indique le test, le scénario synthétique, les versions, la première divergence et l'expiration.
Définissez le contrat attendu avant l'exécution.
Lisez la trace de l'assertion vers le premier état inattendu.
Choisissez captures et instantanés selon la question.
Traitez la taille de l'artefact comme une limite opérationnelle.
Chaque nouvelle tentative utilise un contexte neuf.
Séparez les chemins des workers parallèles.
Limitez l'accès comme pour un secret.
Retirez les données de l'archive et des captures exportées.
Transformez la première divergence en régression ciblée.
Reproduisez dans un dossier propre avec une version nommée.
Remplacez les attentes fragiles par des conditions visibles.
Donnez au service un identifiant pris en charge, pas les données du navigateur.
Rendez le nettoyage observable sans exposer le contenu.
Pour une navigation, comparez la chronologie au signal visible de fin.
Pour une assertion, vérifiez l'instantané et l'état synthétique du fixture.
Pour le réseau, notez la catégorie et le statut documenté, sans copier les en-têtes.
Pour un écart visuel, contrôlez langue, viewport et version avant la base.
Notez l'action suivante après la revue.
Partagez un lien restreint plutôt que l'archive complète.
N'inscrivez pas d'identifiant de compte dans les étiquettes.
Confirmez le serveur avec ses journaux pris en charge.
Gardez seulement le diagnostic retiré après l'incident.
Liste de vérification
- Définissez le scénario autorisé et son assertion.
- Activez le tracing pour le fixture nécessaire.
- Utilisez un chemin privé et unique.
- Retirez les données avant le partage.
- Notez le constat, les versions et l'expiration.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.