Interface Utilisateur de Contrôle – Tests E2E

Que fait Interface Utilisateur de Contrôle – Tests E2E ?

Conception de feedback UI + flux navigateur réels avec données Gateway déterministes.

Test de Résistance UI

• Changements UI substantiels : construire d'abord une galerie HTML locale de test de résistance ; laisser l'utilisateur comparer des états significatifs et donner son feedback sur des exemples concrets.
• Utiliser pour les mises en page, les interactions, les composants avec plusieurs états. Les petites modifications de copie/icône peuvent être ignorées lorsque la galerie n'apporte aucune comparaison utile.

1. Dériver les exemples des composants affectés + des contrats de données. Couvrir les états pertinents : normal, chargement, vide, erreur, indisponible, permission, sélectionné, développé ; texte long/contenu dense là où ils mettent à l'épreuve la mise en page. Afficher les états mutuellement exclusifs séparément ; étiqueter les états proposés non supportés par l'implémentation actuelle.
2. Un aperçu HTML ouvrable dans le navigateur : identifiants d'exemples stables, courtes étiquettes d'état, suffisamment de contexte pour comprendre chaque exemple. Préférer les composants réels + fixtures mock déterministes. Étiqueter les rendus statiques/approximatifs ; lier l'UI en cours pour les interactions qu'ils ne peuvent pas reproduire. Galeries générées : stockage d'artefacts appartenant à la tâche ; pas de commit par défaut.
3. Chaque exemple : entrée de feedback étiquetée. Persister localement après les rechargements avec une clé de stockage spécifique à la galerie + identifiants d'exemples stables. Action Copier le feedback exportant les identifiants d'exemples, les étiquettes d'état, les commentaires au format Markdown/texte brut pour que l'utilisateur les ramène dans la conversation.
4. Ouvrir la galerie dans le navigateur d'aperçu disponible ; partager l'URL/chemin de fichier. Conserver la même galerie, les mêmes identifiants d'exemples, les commentaires existants à travers les itérations. Appliquer le feedback utilisateur à la fois à la galerie + à l'implémentation ; maintenir la comparabilité.
5. Avant de demander un feedback : inspecter les exemples rendus aux tailles de fenêtre pertinentes ; vérifier que le feedback survit au rechargement et exporte les bonnes étiquettes d'exemples. Signaler les états non supportés/limitations de l'aperçu.

La galerie soutient la révision de design ; elle ne remplace jamais les tests de comportement ciblés ni les preuves avant/après inspectées de l'UI en fonctionnement. Conserver la preuve finale dans des répertoires de capture frais ci-dessous, séparés de la galerie en évolution.

Structure des Tests

• Flux GUI complets : ui/src/**/*.e2e.test.ts.
• ui/src/test-helpers/control-ui-e2e.ts : démarrer Vite Control UI + installer une Gateway WebSocket simulée.
• Scénarios déterministes. Pas de clés de fournisseur réelles, ni d'identifiants de canal réels, ni de Gateway réelle sauf si l'utilisateur demande explicitement une preuve en direct.
• Affiner la logique de rendu : préférer les tests .browser.test.ts / tests unitaires existants. La voie E2E : routage, démarrage de l'application, handshake Gateway, requêtes, comportement UI visible ensemble.

Commandes

• Cibler un test E2E dans l'arbre de travail Codex :

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

• Voie locale entière dans un checkout normal :

pnpm test:ui:e2e

• Utiliser une installation de dépendances prête ou un checkout normal préparé ; ne jamais réconcilier une installation partagée pendant que d'autres tâches l'utilisent.
• Suivre $openclaw-testing : une preuve de développement de confiance peut être exécutée localement ; une preuve à distance nécessite une raison de navigateur/plateforme, d'environnement propre ou d'isolation source.

Preuve Visuelle par Défaut

• Changements d'apparence : preuve visuelle inspectée avant/après.
• Autre comportement : preuve de limite la plus claire appropriée ; vidéo + jeu de captures d'écran non obligatoires lorsque les assertions démontrent déjà le changement.
• Assertions Vitest E2E déterministes ; ne jamais commiter de captures d'écran/vidéos générées.
• La suite partagée désactive la rastérisation partielle Chromium + la rastérisation GPU pour éviter les pixels de bord dépendant de l'historique de peinture observés. Des comparaisons exactes répétées sont toujours nécessaires avant de revendiquer la reproductibilité.
• États transitoires tels que Sauvegardé : installer page.clock avant la fixture ; mettre en pause avec pauseVirtualClock ; avancer seulement le travail de fixture nécessaire pour entrer dans l'état. setFixedTime seul ne met pas en pause les minuteurs. La capture de préparation utilise la disposition native sans avancer l'horloge de la fixture.
• Images fixes : takeControlUiScreenshotFrame depuis ui/src/test-helpers/control-ui-e2e-screenshot.ts, contenu sémantique explicite + `animations: