Tester et déboguer la page

L'importance des tests et du débogage dans le développement web

Vous avez défini une route, implémenté la logique dans un contrôleur et créé un template Twig. Félicitations ! Cependant, le travail d'un développeur ne s'arrête pas là. Il est crucial de s'assurer que la page fonctionne comme prévu et de savoir comment identifier et corriger les problèmes qui pourraient survenir. Le test et le débogage sont des compétences aussi importantes que l'écriture du code lui-même.

Même pour une page simple, des erreurs peuvent se glisser : une faute de frappe dans le nom d'une route ou d'une variable Twig, une logique incorrecte dans le contrôleur, un problème de configuration, etc. Savoir comment aborder ces situations vous fera gagner un temps précieux et améliorera la qualité de votre travail.

Symfony, étant un framework pensé pour les développeurs, fournit d'excellents outils pour faciliter ces tâches, surtout en environnement de développement.

Test manuel : Vérifier dans le navigateur

Le premier type de test, et le plus simple, est le test manuel. Une fois que vous pensez que votre page est prête :

1. Assurez-vous que votre serveur de développement Symfony est lancé. Dans votre terminal, à la racine de votre projet, si ce n'est pas déjà fait, exécutez :

   symfony server:start

   Cela démarre généralement un serveur web local sur http://localhost:8000 (ou un autre port s'il est déjà utilisé).
2. Ouvrez votre navigateur web (Chrome, Firefox, Safari, Edge, etc.).
3. Accédez à l'URL de votre page. Dans notre exemple de la page "A Propos", l'URL serait http://localhost:8000/a-propos.

Observez attentivement le résultat :

• Le contenu s'affiche-t-il correctement ? Les textes, images, et autres éléments sont-ils ceux attendus ?
• La mise en page est-elle correcte ? (Bien que nous n'ayons pas encore beaucoup travaillé sur le CSS).
• Les données dynamiques passées par le contrôleur sont-elles bien affichées ? (Par exemple, le titre de la page, la description, la date de création dans notre cas).
• Y a-t-il des messages d'erreur visibles sur la page ?
• Ouvrez la console de développement de votre navigateur (généralement avec F12 ou Clic droit > Inspecter > Console). Vérifiez s'il y a des erreurs JavaScript ou des problèmes de chargement de ressources (CSS, images – même si nous n'en avons pas encore beaucoup).

Si tout semble correct, c'est un bon début ! Si vous rencontrez un problème, les sections suivantes vous aideront à le diagnostiquer.

La Web Debug Toolbar : Votre premier allié en développement

En environnement de développement (APP_ENV=dev dans votre fichier .env, ce qui est le cas par défaut), Symfony affiche une barre d'outils très utile en bas de chaque page de votre application : la Web Debug Toolbar.

Cette barre est une mine d'informations. Survolez ses différentes icônes ou cliquez dessus pour obtenir des détails sur :

• La requête et la réponse : Code de statut HTTP (200 OK, 404 Not Found, 500 Internal Server Error, etc.), informations sur le contrôleur exécuté, la route correspondante.
• Performance : Temps de chargement de la page, utilisation de la mémoire.
• Logs : Messages d'erreur, avertissements, informations de débogage que vous ou les composants Symfony avez pu enregistrer.
• Routage : Détails sur la route qui a correspondu à l'URL actuelle.
• Templates Twig : Liste des templates rendus pour la page, temps de rendu, nombre de blocs et macros appelés. C'est très utile pour vérifier quels templates sont impliqués.
• Formulaires : Si la page contient un formulaire Symfony, des informations détaillées sur celui-ci.
• Doctrine : Si vous utilisez Doctrine, le nombre de requêtes SQL exécutées, leur durée, et le détail des requêtes.
• Configuration : Accès rapide à la configuration de l'application.
• Et bien d'autres choses selon les bundles installés (Sécurité, Mailer, etc.).

Si votre page affiche une erreur 500, la Web Debug Toolbar se transformera souvent en un écran d'erreur détaillé vous indiquant la nature du problème, le fichier et la ligne où il s'est produit, ainsi qu'une trace d'appels (stack trace). C'est souvent le premier endroit où regarder quand quelque chose ne va pas.

Si vous ne voyez pas la Web Debug Toolbar, assurez-vous que :

• Vous êtes bien en environnement de développement (APP_ENV=dev).
• Le bundle DebugBundle et WebProfilerBundle sont installés et activés (ils le sont par défaut dans les projets Symfony standard).

Le Profiler Symfony : Plonger plus profondément

Chaque icône cliquable de la Web Debug Toolbar (ou le token qui apparaît parfois sur les pages d'erreur) mène à une section du Profiler Symfony. Le Profiler est une interface web plus complète qui conserve l'historique des informations collectées pour chaque requête (ou les dernières requêtes, selon la configuration).

Pour accéder directement au Profiler, vous pouvez cliquer sur le token de la requête dans la Web Debug Toolbar (souvent un lien avec un code alphanumérique) ou, si la page d'erreur ne le permet pas, vous pouvez essayer d'accéder à une URL comme http://localhost:8000/_profiler/ pour voir la liste des dernières requêtes.

Le Profiler vous offre une vue bien plus détaillée de tout ce qui s'est passé pendant le traitement de la requête. C'est un outil indispensable pour :

• Analyser les performances : Identifier les goulots d'étranglement, voir quelles parties du code prennent le plus de temps.
• Déboguer les requêtes Doctrine : Examiner les requêtes SQL exactes, le nombre de résultats, etc.
• Comprendre le flux d'événements : Voir quels écouteurs d'événements ont été déclenchés.
• Inspecter les données des formulaires : Voir les données soumises et les erreurs de validation.
• Vérifier la configuration : S'assurer que les paramètres de configuration sont bien pris en compte.

Prenez le temps d'explorer les différentes sections du Profiler pour votre page "A Propos". Même si elle est simple, cela vous familiarisera avec l'outil.

Interpréter les messages d'erreur courants

Lorsque les choses tournent mal, Symfony essaie de vous donner des messages d'erreur aussi clairs que possible, surtout en mode développement. Voici quelques erreurs fréquentes que vous pourriez rencontrer au début :

• NotFoundHttpException (Erreur 404) : La plus courante. Cela signifie que le routeur n'a trouvé aucune route correspondant à l'URL demandée. Vérifiez :
  • L'orthographe de l'URL dans votre navigateur.
  • La définition de votre route (chemin, nom) dans l'attribut #[Route] du contrôleur. Utilisez php bin/console debug:router pour vérifier que votre route est bien enregistrée et avec le bon chemin.
  • Si vous avez des paramètres de route avec des requirements, assurez-vous que l'URL les respecte.
• Erreurs de syntaxe PHP : Si vous avez une erreur de syntaxe dans votre code PHP (contrôleur, autre classe), PHP lèvera une ParseError. Le message d'erreur de Symfony indiquera généralement le fichier et la ligne.
• Erreurs dans Twig :
  • Variable "nom_variable" does not exist. : Vous essayez d'utiliser une variable dans Twig ({{ nom_variable }}) qui n'a pas été passée par le contrôleur dans le tableau associatif de la méthode render(), ou vous avez fait une faute de frappe dans son nom.
  • Unknown "nom_filtre" filter. ou Unknown "nom_fonction" function. : Vous essayez d'utiliser un filtre ou une fonction Twig qui n'existe pas ou qui n'est pas disponible.
  • Erreurs de syntaxe Twig (par exemple, un {% if %} non fermé par {% endif %}). La page d'erreur de Twig est généralement très explicite.
• Controller "App\Controller\MonController::maMethode()" not found or is not a callable. : Le routeur a trouvé une route, mais le contrôleur ou la méthode spécifiée dans la route n'existe pas, n'est pas publique, ou il y a une faute de frappe dans le nom de la classe ou de la méthode.
• Problèmes de services / Autowiring : Si vous essayez d'injecter un service dans votre contrôleur et que Symfony ne peut pas le trouver ou le construire, vous aurez une erreur liée au conteneur de services.

La clé est de lire attentivement le message d'erreur et la trace d'appels (stack trace). La trace vous montre la séquence d'appels de fonctions qui a conduit à l'erreur, ce qui aide à localiser la source du problème. Commencez par regarder les premières lignes de la trace qui concernent votre propre code (généralement dans src/).

Utiliser `dump()` pour inspecter des variables

Parfois, vous avez besoin de voir le contenu d'une variable à un certain point de l'exécution de votre code PHP (dans un contrôleur, par exemple) ou dans un template Twig. Symfony fournit une fonction dump() extrêmement utile, qui est une version améliorée de var_dump() de PHP.

Dans un contrôleur PHP :

// ... dans une méthode de contrôleur
$maVariableComplexe = ['a' => 1, 'b' => new DateTime()];

dump($maVariableComplexe); // Affiche le contenu de la variable dans la Web Debug Toolbar (section "Debug") et sur la page si rien d'autre n'est retourné après.
// die; // Souvent utile après un dump pour arrêter l'exécution et voir uniquement le dump.

return $this->render(...);

Dans un template Twig :

{# templates/static_page/about.html.twig #}
{{ dump(page_title) }}
{{ dump(creation_date) }}
{{ dump() }} {# Sans argument, dump() affiche toutes les variables disponibles dans le contexte du template #}

<h1>{{ page_title }}</h1>
{# ... reste du template ... #}

Les résultats de dump() sont affichés de manière interactive et lisible dans la section "Debug" de la Web Debug Toolbar (accessible via l'icône cible/réticule) et également dans le Profiler. C'est un excellent moyen d'inspecter des objets complexes, des tableaux, et de vérifier que les données que vous manipulez sont celles que vous attendez.

N'oubliez pas de retirer les appels à dump() de votre code de production !

En maîtrisant ces techniques de test et de débogage, vous serez beaucoup plus efficace pour construire et maintenir vos applications Symfony. La Web Debug Toolbar et le Profiler deviendront rapidement vos meilleurs amis.