Tests, console, événements et composants utiles

Comprendre le mécanisme

Un test unitaire isole une règle ; un KernelTestCase permet de travailler avec le conteneur ; un WebTestCase exerce le parcours HTTP avec un client de test. Les assertions doivent porter sur des effets observables, y compris les refus et les erreurs. Le profiler et la barre de debug servent au diagnostic de développement, pas à l’exposition publique des secrets. Les commandes Console ont des arguments, options, codes de sortie et niveaux de verbosité.

Raisonner et vérifier

Pour les composants annexes, conservez le même raisonnement de contrat : Clock facilite un temps contrôlable, EventDispatcher découple la notification, Filesystem et Finder manipulent les fichiers, Process exécute un processus avec arguments explicites. Mailer/Mime construisent et envoient des messages ; leur transport doit être substituable en test. Le Serializer exige un périmètre de données choisi. Testez échec de commande, environnement et absence de réseau imposé.

Isoler un contrat

Un test unitaire cible un contrat isolé. Son périmètre est plus limité. Un test unitaire d’une règle de remise peut injecter catalogue et horloge. Contrôlez entrées, résultat et appels significatifs ; un test qui copie chaque ligne de l’implémentation protège mal le comportement attendu.

Parcours HTTP

Un test fonctionnel vérifie un parcours applicatif. Les données et environnements doivent être isolés. WebTestCase fournit un client de test pour exercer le kernel. Vérifiez statut, contenu et absence d’effet interdit ; remplacez seulement les frontières réellement externes, sans contourner le contrôle d’accès que vous voulez mesurer.

Code de sortie

Une commande doit retourner un code de sortie adapté. Le processus appelant utilise aussi le code de retour. Une commande de migration partielle doit retourner un échec non nul lorsqu’elle n’a pas satisfait son contrat. Les scripts CI utilisent ce signal ; une ligne rouge imprimée avec code zéro peut laisser continuer la release.

Entrées de commande

Les entrées de commande doivent être validées. Un opérateur ou automate peut fournir une valeur incorrecte. Validez nom de fichier, identifiant et options avant utilisation. Un appel CLI interne reste exposé aux erreurs de l’opérateur et à une donnée provenant d’un autre système ; un prompt interactif n’est pas une validation.

Sorties minimisées

Les secrets ne doivent pas être imprimés par défaut. Le diagnostic doit minimiser les capacités sensibles. Évitez de copier une URL de connexion contenant un mot de passe dans les logs CI. Préférez un diagnostic de composant et un identifiant de corrélation, avec détails protégés dans un canal approprié.

Fixtures cohérentes

Les fixtures doivent respecter les invariants. Le scénario doit préparer ses préconditions. Une fixture de réservation doit respecter relations, contraintes et états possibles. Si elle contourne ces règles, un test vert peut décrire une situation que la production ne peut jamais atteindre.

Horloge contrôlable

Une horloge injectée rend les délais testables. La dépendance temporelle peut être contrôlée. Injectez une horloge pour comparer maintenant à expiresAt. Testez juste avant, à la borne et après l’expiration ; le choix inclusif ou exclusif doit être explicite et reproductible sans attente réelle.

Refus de méthode

Les méthodes refusées méritent un test. Les chemins d’accès peuvent différer. Un endpoint prévu en POST doit être essayé en GET. Vérifiez le rejet et l’absence de mutation, sans réduire le test à la présence d’un bouton qui n’envoie normalement que la bonne méthode.

Cycle de kernel

Le kernel et les services ont un cycle à respecter. Les fuites d’état rendent les résultats dépendants de l’ordre. Le client de test peut redémarrer le kernel entre demandes. Ne supposez pas qu’une instance récupérée avant la première requête sera nécessairement celle utilisée ensuite ; configurez les doubles au bon moment.

Portée des preuves

Une suite verte ne certifie pas toute sécurité réelle. Les garanties dépendent des cas et hypothèses couverts. Une suite ne couvre que les cas et hypothèses exécutés. Ajoutez revues, analyse des dépendances et contrôles d’exploitation ; consignez version et environnement pour savoir à quelle release le résultat s’applique.

Atelier guidé : lire, expliquer et vérifier le code

// Après détection d’un échec de sauvegarde :
$output->writeln('Backup failed');
return Command::SUCCESS;

La commande illustrée affiche un message d’échec tout en pouvant signaler un succès au système appelant. Exécutez-la avec CommandTester et vérifiez ensemble contenu utile et code de sortie. Ajoutez un cas d’entrée invalide et un cas nominal. L’objectif est un contrat exploitable par une personne comme par un script.

Les commandes ont précisément un statut de sortie. Une CI peut se fier au code de sortie plutôt qu’au texte. L’affichage ne change pas le code retourné. La constante ne restaure pas les données.

Travail pratique : Écrivez une commande de vérification qui retourne un code non nul quand une dépendance indispensable manque.

Critères de correction : Injectez une abstraction de vérification, testez succès et échec avec CommandTester et vérifiez le code de sortie. Pour HTTP, testez un parcours complet et un refus d’accès sans base de production.