Control UI E2E

Was macht Control UI E2E?

Arbeitsablauf

1. Nachweis auswählen. Verwenden Sie die vorhandene Browser-E2E-Spur für Routing, Boot, Gateway-Handshake und vollständige Benutzerabläufe; verwenden Sie Browser/Unit-Tests für isolierte Rendering-Logik. Lesen Sie jeden Zweig unten, der zum angeforderten Ergebnis passt.
   Erledigt: Jedes geänderte Verhalten hat ein benanntes Szenario und eine Nachweisgrenze.
2. Fixtures vorbereiten. Wiederverwenden Sie ui/src/test-helpers/control-ui-e2e.ts mit synthetischen Gateway-Daten. Erweitern Sie dessen typisierte Szenario-Optionen für fehlende Antworten. Verwenden Sie die vorhandene Abhängigkeitsinstallation; bewahren Sie Installationen, die von anderen Jobs verwendet werden. Echte Gateway-/Anbieter-Anmeldedaten erfordern explizite Live-Proof-Autorisierung. Befolgen Sie die Testrichtlinie für die Ausführungsplatzierung.
   Erledigt: Der Zielablauf läuft gegen den beabsichtigten Quell- oder Produktions-Build und jede erforderliche Fixture-Antwort ist definiert.
3. Verhalten ausführen. Installieren Sie den Mock vor der Navigation. Handeln Sie über sichtbare Steuerelemente und bestätigen Sie sowohl das gerenderte Ergebnis als auch relevante Gateway-Anfragen. Lösen Sie unerwartetes Verhalten beim Produkt- oder Fixture-Eigentümer, bevor Sie erneut abspielen.
   Erledigt: Jedes Szenario erreicht sein bestätigtes Ergebnis oder hat einen beibehaltenen Fehler, der die nicht erfüllte Behauptung identifiziert.
4. Nachweise liefern. Wenden Sie die Artefaktregeln unten und die Prüfungen des ausgewählten Zweigs an. Melden Sie verifizierte Ergebnisse, Fehler und nicht getestete Zustände getrennt.
   Erledigt: Jedes behauptete Ergebnis hat überprüfbare Nachweise; verbleibende Lücken sind benannt.

UI-Stresstest

Für erhebliche Layout-/Komponentenänderungen oder mehrstaatliches Design-Feedback lesen Sie visueller Nachweis, bevor Sie die Stresstest-Galerie erstellen. Kleine Text-/Symboländerungen können fokussierte Nachweise verwenden.

Standard für visuelle Nachweise

Für Aussehensänderungen, Screenshots, Aufnahmen flüchtiger Zustände oder Videos lesen Sie visueller Nachweis. Aussehensänderungen erfordern überprüfte Vorher-/Nachher-Nachweise; Verhaltensbehauptungen allein können für nichtvisuelle Korrekturen ausreichen.

Interaktions-Performance-Audits

Bei UI-Trägheit, Reaktionsfähigkeitsaudits oder automatischer Chrome-Trace-Erfassung lesen Sie Interaktionsprofilerstellung, bevor Sie Build, Fixtures und Messgrenzen auswählen.

Run-Inspector-Nachweise

Für Ausführungs-/Entscheidungsnachweise lesen Sie Run-Inspector-Erfassung, bevor Sie einen Beleg auswählen.

Artefakte

• Weisen Sie mit createControlUiE2eArtifactDir(scope, parentDir?) zu, einmal pro Versuch oder eigenständigem Aufruf. Übergeben Sie das Verzeichnis an Erfassungshelfer; behalten Sie unterschiedliche Stufendateinamen und halten Sie Bericht, Screenshots, Traces und Video zusammen.
• Der Helfer besitzt die Elternauswahl. Bewahren Sie vorhandene Ausgabesteuerungen, Sperren, Viewport und Aufzeichnungsoptionen; verwenden Sie dessen zurückgegebenen Pfad im endgültigen Bericht.
• Behalten Sie fehlgeschlagene und erfolgreiche Versuche. Bereinigen Sie nur exakt eigene Verzeichnisse nach der Überprüfung; löschen Sie niemals gemeinsame Artefakt-Eltern oder überschreiben Sie frühere Nachweise.
• Timeout-Diagnosen verwenden frische Kinder ihres vorhandenen Diagnose-Eltern. Mantis behält jeden Versuch. Real-Gateway-, chat-outbox-*- und chat-attachment-read-lifecycle-Suites haben separate Eigentümer: Überprüfen Sie deren Aufbewahrungsverhalten, bevor Sie eine wiederholungssichere Erfassung beanspruchen.

Ausführen eines fokussierten Tests

Verwenden Sie die aktuellen Skripte in package.json und die Testrichtlinie. Für einen fokussierten Browser-Test in einem Arbeitsbaum:

node scripts/run-vitest.mjs run --config test/vitest/vitest.ui-e2e.config.ts --configLoader runner ui/src/e2e/chat-flow.messaging.e2e.test.ts