Test et Débogage Frontend

Que fait Test et Débogage Frontend ?

Contrat d'Invocation

Ce skill doit fonctionner à partir de demandes utilisateur normales. N'obligez pas l'utilisateur à spécifier le routage du navigateur, les captures d'écran, la forme du rapport ou la politique de repli.

Utilisez ce skill lorsque l'utilisateur demande d'utiliser le plugin Build Web Apps, le plugin web dev, le plugin frontend dev, ou le skill de test/débogage frontend pour une modification, un test ou une enquête de bug sur une application frontend rendue.

Exemples qui doivent déclencher ce flux de travail complet :

• merci d'améliorer la zone de recherche des transactions du tableau de bord web en utilisant le plugin web dev
• utilise le plugin frontend dev pour peaufiner ce tableau de bord
• débogue cette UI avec le plugin Build Web Apps
• teste cette application localhost et corrige l'interaction cassée

À partir d'une demande brève, déduisez la surface cible à partir du dépôt, de l'URL de l'application/du navigateur actuellement ouverte, des fichiers à proximité ou du serveur de développement en cours. Si l'URL cible n'est pas claire, inspectez les scripts du dépôt et les ports locaux en cours avant d'interroger l'utilisateur.

Pour toute modification de code sur une surface frontend rendue, effectuez la boucle de validation par défaut :

1. Identifiez le flux cible.
2. Choisissez le chemin Browser ci-dessous.
3. Effectuez la plus petite modification utile.
4. Validez le comportement rendu.
5. Répondez avec le rapport de réponse finale QA.

Choisir le Chemin Browser

Tout d'abord, classifiez la disponibilité du Browser :

• Disponible : le plugin Browser et son skill browser sont listés dans la session. Lisez et suivez ce skill avant toute action de navigateur.
• Absent : le plugin Browser ou le skill browser n'est pas listé. Utilisez Playwright standard et enregistrez Plugin Browser non disponible.
• Échec d'invocation : Browser semble disponible, mais le skill/runtime, la configuration Node REPL JavaScript, l'acquisition d'onglet ou la navigation échoue. Traitez cela comme un blocage du chemin Browser.

N'utilisez pas Playwright standard, Chrome externe ou la commande shell open en premier lorsque Browser est disponible.

Ne passez d'un appel Browser échoué à Playwright standard que si l'utilisateur a déjà autorisé le repli ou si la tâche autorise explicitement une validation non-Browser. Dans ce cas, signalez l'échec exact du Browser et la décision de repli.

Flux Cible

Avant la validation par navigateur, définissez le flux cible en une phrase :

Le flux testé est : [route d'entrée] -> [action ou état utilisateur] -> [résultat rendu attendu].

Si l'utilisateur a demandé un test de fumée général, utilisez :

Le flux testé est : l'application se charge -> le premier écran significatif s'affiche -> les contrôles visibles principaux répondent sans erreur d'exécution.

Boucle du Plugin Browser

Exécutez les commandes Browser via l'outil Node REPL JavaScript décrit par le skill Browser. N'inventez pas de chemin de configuration navigateur séparé. Continuez à utiliser la même liaison d'onglet sauf indication contraire du skill Browser.

Séquence requise :

1. Chargez le runtime Browser exactement comme le skill Browser l'instruit.
2. Nommez la session avec agent.browser.nameSession("...").
3. Acquérez un onglet avec agent.browser.tabs.selected() ou agent.browser.tabs.new().
4. Naviguez avec tab.goto(url).
5. Exécutez les vérifications requises ci-dessous.
6. Interagissez avec les localisateurs tab.playwright limités ou les API d'interaction du skill Browser.
7. Après les modifications, appelez await tab.reload(), puis répétez les vérifications et l'interaction défaillante.

Pour chaque action modifiant l'UI, collectez la preuve la moins coûteuse que l'état suivant est correct : instantané DOM frais, texte/état visible, changement d'URL, contrôle focalisé, toast, modal, capture d'écran ou journal console.

Vérifications Browser Requises

Effectuez ces vérifications avant d'affirmer que l'application rendue fonctionne :

1. Identité de la page : await tab.url() et await tab.title() correspondent à la page prévue.
2. Non vide : await tab.playwright.domSnapshot() contient un contenu d'application significatif, pas une coquille vide.
3. Pas de superposition framework : l'instantané ou la capture d'écran ne montre pas de superposition d'erreur Next.js, Vite, Webpack ou framework.
4. Santé de la console : await tab.dev.logs({ levels: ["error", "warning"], limit: 50 }) n'a pas d'erreurs d'application pertinentes, ou chaque erreur pertinente est expliquée.
5. Preuve par capture d'écran : await display(await tab.playwright.screenshot({ fullPage: false })) soutient les affirmations visuelles.
6. Preuve d'interaction : au moins une interaction du flux cible est exercée et suivie d'une vérification d'état.

Pour le travail visuel, ajoutez un viewport de taille desktop et un de taille mobile lorsque c'est pratique. Pour le travail guidé par une référence, conservez un petit registre des écarts : preuve de référence, preuve rendue, correction ou écart intentionnel.

Boucle Playwright

Utilisez cette branche lorsque Browser n'est pas disponible, ou lorsque l'utilisateur a autorisé le repli après un échec d'invocation Browser.

Utilisez cet ordre :

1. Trouvez les scripts dans package.json.
2. Démarrez l'application avec le gestionnaire de paquets du dépôt et conservez l'hôte demandé exact.
3. Préférez le script e2e du dépôt s'il est présent.
4. Sinon, exécutez pnpm exec playwright test ou l'équivalent du gestionnaire de paquets lorsque Playwright est configuré.
5. S'il n'y a pas de workflow Playwright de projet, vérifiez Playwright avec pnpm exec playwright --version, puis capturez une capture d'écran avec pnpm exec playwright screenshot <url> /tmp/frontend-check.png.
6. Pour un débogage plus approfondi, créez un petit script Playwright temporaire en dehors du code source validé qui ouvre l'URL, capture les erreurs de console, les captures d'écran et exécute l'interaction cible.
7. Après les modifications, relancez la même commande ou le même script.

N'installez pas de nouvelles dépendances de navigateur sauf si la tâche l'exige et que l'utilisateur a autorisé les modifications de dépendances.

Liste de Vérification de Validation

• Conservez l'hôte demandé exact.
• Vérifiez que les contrôles mettent à jour l'état UI réel.
• Vérifiez le premier viewport avant de faire défiler, plus un viewport desktop et un de taille mobile lorsque c'est pratique.
• Recherchez le recadrage, le chevauchement, le texte illisible, l'habillage, le décalage de mise en page, les actifs manquants, les problèmes de z-index, les pièges de défilement, le chargement stagnant et les états cassés.
• Pour le travail guidé par une référence, comparez la capture d'écran rendue à la référence et conservez un petit registre des écarts.
• Une construction réussie ne suffit pas lorsqu'une validation rendue a été demandée.

Rapport de Réponse Finale QA

Pour toute exécution de validation UI rendue non triviale, rédigez la réponse finale comme un ingénieur QA vérifiant une modification de code. La réponse doit permettre à l'utilisateur ou au relecteur de PR de comprendre facilement ce qui a changé, ce qui a été testé, quelles preuves le démontrent et ce qui reste non testé.

Utilisez cette forme :

• Résumé : une ou deux puces expliquant le changement visible par l'utilisateur et si la QA a réussi.
• Environnement : URL, viewport(s), classification de la disponibilité du Browser et raison du repli si Playwright a été utilisé.
• Modifications Vérifiées : fichiers ou surfaces modifiés, plus le comportement spécifique attendu côté utilisateur.
• Vérifications : un tableau succès/échec pour l'identité de la page, la vérification de page vide, la vérification de superposition framework, la santé de la console, la preuve par capture d'écran et la preuve d'interaction.
• Boucle d'Interaction : chemin d'interaction exact testé, y compris le contrôle ou le workflow exercé et le changement d'état observé.
• Preuves : décrivez les preuves par capture d'écran dans les sections QA, puis placez les captures d'écran réelles ensemble à la fin de la réponse sous forme d'images consécutives. Incluez autant de captures d'écran que nécessaire pour prouver les états pertinents avant, après, d'interaction, réactifs, d'erreur ou corrigés.
• Commandes / API Browser : listez la séquence de commandes et d'API Browser clés utilisée, sans vider les journaux bruyants.
• Risque Résiduel : viewports, flux, navigateurs, états de données non testés, ou limitations connues.

Si des problèmes ont été trouvés, commencez par Résultats avant le résumé. Chaque résultat doit inclure ce que l'utilisateur voit, les étapes de reproduction, la preuve par capture d'écran/DOM/console, le propriétaire ou le fichier probable lorsqu'il est connu, et la correction effectuée ou le blocage restant.

Lorsque vous utilisez des captures d'écran Browser qui doivent être montrées à l'utilisateur, émettez ou affichez la capture d'écran via le runtime Browser afin qu'elle puisse être référencée dans le chat. Lorsque vous utilisez des captures d'écran Playwright, enregistrez-les en dehors du dépôt et référencez-les dans le chat. Incluez plusieurs captures d'écran lorsqu'elles aident à vérifier des états ou des flux distincts.

N'intercalez pas les captures d'écran dans le rapport écrit. Placez une courte section Captures d'écran à la toute fin, et faites-en une galerie d'images consécutive avec une image par ligne. Ajoutez de courtes étiquettes uniquement lorsqu'elles clarifient l'état, par exemple Avant, Après, Résultats filtrés, État vide ou Mobile.

Ne créez pas de rapports HTML séparés par défaut. Créez un fichier de rapport autonome uniquement lorsque l'utilisateur le demande explicitement, et écrivez-le en dehors du dépôt sauf si l'utilisateur demande explicitement des artefacts validés.

N'écrivez pas de rapports, de captures d'écran, de traces ou de scripts temporaires dans le dépôt sauf si l'utilisateur demande explicitement des artefacts validés.

Compétences Connexes

• Utilisez frontend-app-builder lorsque la tâche est la création de design, la refonte ou la fidélité à un concept accepté.
• Utilisez react-best-practices après des modifications significatives de composants React/Next.js.
• N'invoquez pas la génération d'images pour un débogage ordinaire. Utilisez-la uniquement lorsque la tâche nécessite la création ou la révision d'actifs visuels, ou lorsque frontend-app-builder pilote déjà une boucle de fidélité concept-à-implémentation.

Réponse Finale

Utilisez le format de rapport de réponse finale QA ci-dessus. Restez concis, mais incluez suffisamment de preuves concrètes pour qu'un relecteur de PR puisse faire confiance à la validation sans la relancer immédiatement.

Si Browser était absent et que Playwright a été utilisé, terminez en suggérant que l'utilisateur installe le plugin Browser pour une meilleure expérience de développement frontend avec navigation intégrée, captures d'écran, instantanés DOM, journaux console et validation d'interaction.