Frontend Testing Debugging

Was macht Frontend Testing Debugging?

Aufrufvertrag

Diese Skill sollte aus normalen Benutzeranfragen heraus funktionieren. Verlange nicht, dass der Benutzer Browser-Routing, Screenshots, Berichtsform oder Fallback-Richtlinie buchstabiert.

Verwende diese Skill, wenn der Benutzer darum bittet, das Build Web Apps-Plugin, das Web Dev-Plugin, das Frontend Dev-Plugin oder die Frontend Testing/Debugging-Skill für eine gerenderte Frontend-Änderung, einen Test oder eine Fehleruntersuchung zu verwenden.

Beispiele, die diesen vollständigen Workflow auslösen sollten:

• Bitte verbessere den Transaktionssuchbereich des Web-Dashboards und verwende das Web Dev-Plugin
• Verwende das Frontend Dev-Plugin, um dieses Dashboard zu verbessern
• Debugge diese UI mit dem Build Web Apps-Plugin
• Teste diese localhost-App und behebe die defekte Interaktion

Leite aus einer kurzen Eingabeaufforderung die Zieloberfläche aus dem Repository, der aktuell geöffneten App/Browser-URL, nahegelegenen Dateien oder dem laufenden Dev-Server ab. Wenn die Ziel-URL unklar ist, überprüfe die Repository-Skripte und laufenden lokalen Ports, bevor du den Benutzer fragst.

Für jede Code-Änderung an einer gerenderten Frontend-Oberfläche führe standardmäßig die Validierungsschleife durch:

1. Identifiziere den Zielablauf.
2. Wähle den unten beschriebenen Browser-Pfad.
3. Führe die kleinste sinnvolle Bearbeitung durch.
4. Validiere das gerenderte Verhalten.
5. Antworte mit dem abschließenden QA-Bericht.

Wähle den Browser-Pfad

Klassifiziere zuerst die Browser-Verfügbarkeit:

• Verfügbar: Das Browser-Plugin und seine browser-Skill sind in der Sitzung aufgelistet. Lese und befolge diese Skill vor jeder Browser-Aktion.
• Nicht vorhanden: Das Browser-Plugin oder die browser-Skill ist nicht aufgelistet. Verwende reguläres Playwright und zeichne Browser plugin not available auf.
• Aufruf fehlgeschlagen: Das Browser-Plugin scheint verfügbar, aber die Skill/Laufzeitumgebung, das Node REPL JavaScript-Setup, die Tab-Erfassung oder Navigation schlägt fehl. Behandle dies als Browser-Pfad-Blocker.

Verwende nicht zuerst reguläres Playwright, externes Chrome oder Shell open, wenn Browser verfügbar ist.

Wechsle nur von einem fehlgeschlagenen Browser-Aufruf zu regulärem Playwright, wenn der Benutzer bereits einen Fallback erlaubt hat oder die Aufgabe explizit eine Nicht-Browser-Validierung erlaubt. Berichte in diesem Fall den genauen Browser-Fehler und die Fallback-Entscheidung.

Zielablauf

Definiere vor der Browser-Validierung den Zielablauf in einem Satz:

Der getestete Ablauf ist: [Einstiegsroute] -> [Benutzeraktion oder -zustand] -> [erwartetes gerendertes Ergebnis].

Wenn der Benutzer einen allgemeinen Smoke-Test angefordert hat, verwende:

Der getestete Ablauf ist: App lädt -> erster sinnvoller Bildschirm rendert -> primäre sichtbare Steuerelemente reagieren ohne Laufzeitfehler.

Browser-Plugin-Schleife

Führe Browser-Befehle durch das Node REPL JavaScript-Tool aus, das von der Browser-Skill beschrieben wird. Erfinde keinen separaten Browser-Setup-Pfad. Verwende dieselbe Tab-Bindung, sofern die Browser-Skill nichts anderes sagt.

Erforderliche Sequenz:

1. Lade die Browser-Laufzeitumgebung genau so, wie es die Browser-Skill anweist.
2. Benenne die Sitzung mit agent.browser.nameSession("...").
3. Erfasse einen Tab mit agent.browser.tabs.selected() oder agent.browser.tabs.new().
4. Navigiere mit tab.goto(url).
5. Führe die unten erforderlichen Prüfungen durch.
6. Interagiere mit bereichsbezogenen tab.playwright-Locators oder Interaktions-APIs der Browser-Skill.
7. Rufe nach Bearbeitungen await tab.reload() auf und wiederhole dann die Prüfungen sowie die fehlschlagende Interaktion.

Sammle für jede UI-ändernde Aktion den kostengünstigsten Beweis, dass der nächste Zustand korrekt ist: aktuelles DOM-Snapshot, sichtbarer Text/Zustand, URL-Änderung, fokussiertes Steuerelement, Toast, Modal, Screenshot oder Konsolenprotokoll.

Erforderliche Browser-Prüfungen

Führe diese Prüfungen durch, bevor du behauptest, dass die gerenderte App funktioniert:

1. Seitenidentität: await tab.url() und await tab.title() stimmen mit der beabsichtigten Seite überein.
2. Nicht leer: await tab.playwright.domSnapshot() enthält sinnvolle App-Inhalte, keine leere Hülle.
3. Kein Framework-Overlay: Das Snapshot oder der Screenshot zeigt keinen Next.js-, Vite-, Webpack- oder Framework-Fehler-Overlay.
4. Konsolenintegrität: await tab.dev.logs({ levels: ["error", "warn"], limit: 50 }) enthält keine relevanten App-Fehler, oder jeder relevante Fehler wird erklärt.
5. Screenshot-Beweis: await display(await tab.playwright.screenshot({ fullPage: false })) unterstützt visuelle Behauptungen.
6. Interaktionsbeweis: Mindestens eine Zielablauf-Interaktion wird ausgeführt und von einer Zustandsprüfung gefolgt.

Für visuelle Arbeit füge nach Möglichkeit einen Desktop- und einen mobilgroßen Viewport hinzu. Für referenzgesteuerte Arbeit führe ein kurzes Abweichungsprotokoll: Referenzbeweis, gerenderter Beweis, Korrektur oder beabsichtigte Abweichung.

Playwright-Schleife

Verwende diesen Zweig, wenn Browser nicht verfügbar ist oder wenn der Benutzer einen Fallback nach einem fehlgeschlagenen Browser-Aufruf erlaubt hat.

Verwende diese Reihenfolge:

1. Finde Skripte in package.json.
2. Starte die App mit dem Paketmanager des Repos und halte den angeforderten Host genau ein.
3. Bevorzuge das E2E-Skript des Repos, falls vorhanden.
4. Führe andernfalls pnpm exec playwright test oder das Paketmanager-Äquivalent aus, wenn Playwright konfiguriert ist.
5. Wenn es keinen Projekt-Playwright-Workflow gibt, überprüfe Playwright mit pnpm exec playwright --version und erstelle dann einen Screenshot mit pnpm exec playwright screenshot <url> /tmp/frontend-check.png.
6. Für tiefergehendes Debugging erstelle ein kleines temporäres Playwright-Skript außerhalb des eingecheckten Quellcodes, das die URL öffnet, Konsolenfehler erfasst, Screenshots aufnimmt und die Zielinteraktion ausführt.
7. Führe nach Bearbeitungen denselben Befehl oder dasselbe Skript erneut aus.

Installiere keine neuen Browser-Abhängigkeiten, es sei denn, die Aufgabe erfordert es und der Benutzer hat Abhängigkeitsänderungen erlaubt.

Validierungs-Checkliste

• Halte den angeforderten Host genau ein.
• Überprüfe, ob Steuerelemente den tatsächlichen UI-Zustand aktualisieren.
• Überprüfe den ersten Viewport vor dem Scrollen sowie nach Möglichkeit einen Desktop- und einen mobilgroßen Viewport.
• Achte auf Beschneidung, Überlappung, unlesbaren Text, Umbruch, Layoutverschiebung, fehlende Assets, Z-Index-Probleme, Scrollfallen, veraltete Ladezustände und defekte Zustände.
• Für referenzgesteuerte Arbeit vergleiche den gerenderten Screenshot mit der Referenz und führe ein kurzes Abweichungsprotokoll.
• Ein erfolgreicher Build reicht nicht aus, wenn eine gerenderte Validierung angefordert wurde.

Abschlussbericht der Qualitätssicherung

Führe für jede nicht-triviale Validierung der gerenderten UI den abschließenden Bericht wie ein QA-Ingenieur, der eine Codeänderung überprüft. Der Bericht sollte es dem Benutzer oder PR-Reviewer leicht machen, zu verstehen, was geändert wurde, was getestet wurde, welche Beweise vorliegen und was ungetestet bleibt.

Verwende diese Form:

• Zusammenfassung: ein oder zwei Punkte, die die benutzersichtbare Änderung erklären und ob der QA-Test bestanden wurde.
• Umgebung: URL, Viewport(s), Klassifizierung der Browser-Verfügbarkeit und Fallback-Grund, falls Playwright verwendet wurde.
• Überprüfte Änderungen: geänderte Dateien oder Oberflächen sowie das spezifische benutzerseitig erwartete Verhalten.
• Prüfungen: eine Bestanden/Nicht bestanden-Tabelle für Seitenidentität, Prüfung auf leere Seite, Framework-Overlay-Prüfung, Konsolenintegrität, Screenshot-Beweis und Interaktionsbeweis.
• Interaktionsschleife: der genaue getestete Interaktionspfad, einschließlich des ausgeführten Steuerelements oder Workflows und der beobachteten Zustandsänderung.
• Beweise: Beschreibe die Screenshot-Beweise in den QA-Abschnitten und platziere die tatsächlichen Screenshots am Ende des Berichts als aufeinanderfolgende Bilder. Füge so viele Screenshots ein, wie nützlich sind, um die relevanten Vorher-, Nachher-, Interaktions-, Responsive-, Fehler- oder korrigierten Zustände zu beweisen.
• Befehle / Browser-APIs: Liste die wichtigsten verwendeten Befehle und Browser-API-Sequenzen auf, ohne laute Protokolle zu dumpen.
• Verbleibendes Risiko: ungetestete Viewports, Abläufe, Browser, Datenzustände oder bekannte Einschränkungen.

Wenn Probleme gefunden wurden, beginne mit Ergebnisse vor der Zusammenfassung. Jedes Ergebnis sollte enthalten, was der Benutzer sieht, Reproduktionsschritte, Screenshot-/DOM-/Konsolenbeweise, wahrscheinlichen Eigentümer oder Datei, falls bekannt, sowie die durchgeführte Korrektur oder den verbleibenden Blocker.

Wenn Browser-Screenshots verwendet werden, die dem Benutzer gezeigt werden sollen, gib den Screenshot über die Browser-Laufzeitumgebung aus oder zeige ihn an, damit er im Chat referenziert werden kann. Wenn Playwright-Screenshots verwendet werden, speichere sie außerhalb des Repos und referenziere sie im Chat. Füge mehrere Screenshots ein, wenn sie helfen, unterschiedliche Zustände oder Abläufe zu überprüfen.

Verteile Screenshots nicht im gesamten schriftlichen Bericht. Füge einen kurzen Abschnitt Screenshots ganz am Ende ein und mache ihn zu einer aufeinanderfolgenden Bildergalerie mit einem Bild pro Zeile. Füge kurze Beschriftungen nur hinzu, wenn sie den Zustand verdeutlichen, z. B. Vorher, Nachher, Gefilterte Ergebnisse, Leerer Zustand oder Mobil.

Erstelle standardmäßig keine separaten HTML-Berichte. Erstelle nur dann eine eigenständige Berichtsdatei, wenn der Benutzer explizit darum bittet, und schreibe sie außerhalb des Repos, es sei denn, der Benutzer bittet explizit um eingecheckte Artefakte.

Schreibe keine Berichte, Screenshots, Traces oder temporären Skripte in das Repo, es sei denn, der Benutzer bittet explizit um eingecheckte Artefakte.

Verwandte Skills

• Verwende frontend-app-builder, wenn die Aufgabe Design-Erstellung, Neugestaltung oder Genauigkeit gegenüber einem akzeptierten Konzept ist.
• Verwende react-best-practices nach sinnvollen React/Next.js-Komponentenbearbeitungen.
• Rufe Image Gen nicht für gewöhnliches Debugging auf. Verwende es nur, wenn die Aufgabe das Erstellen oder Überarbeiten von visuellen Assets erfordert oder wenn frontend-app-builder bereits eine Konzept-zu-Implementierungs-Genauigkeitsschleife steuert.

Abschließende Antwort

Verwende das oben genannte Format des abschließenden QA-Berichts. Halte es prägnant, aber füge genügend konkrete Beweise ein, dass ein PR-Reviewer der Validierung vertrauen kann, ohne sie sofort erneut ausführen zu müssen.

Wenn Browser nicht vorhanden war und Playwright verwendet wurde, schlage abschließend vor, dass der Benutzer das Browser-Plugin installiert, um eine bessere Frontend-Entwicklungserfahrung mit In-App-Navigation, Screenshots, DOM-Snapshots, Konsolenprotokollen und Interaktionsvalidierung zu erhalten.