Tester l’application de bout en bout

Une page peut sembler correcte lorsqu’elle est ouverte seule et pourtant échouer dans le parcours réel : lien mal formé, image absente ou retour vers la mauvaise destination. Vous allez tester le catalogue comme le ferait un visiteur, puis vérifier que Next.js compile l’ensemble du projet sans erreur.

1. Démarrer une vérification propre

Placez-vous à la racine du projet sentiers-randonnees, puis démarrez le serveur de développement avec la commande utilisée dans la première leçon. Gardez le terminal ouvert : il affiche les erreurs de compilation et les problèmes détectés pendant le chargement des pages. Dans le navigateur, ouvrez l’adresse locale indiquée par le serveur et vérifiez que la page d’accueil répond.

npm run dev

Le terminal indique que le serveur de développement est prêt et affiche l’adresse locale à ouvrir dans votre navigateur.

Effectuez le parcours sans supposer qu’un lien fonctionne parce que son adresse paraît correcte. Depuis l’accueil, ouvrez chaque carte, contrôlez le contenu de la page obtenue, puis utilisez le lien de retour au catalogue. Recommencez pour les deux itinéraires afin de repérer une erreur qui ne concernerait qu’une seule donnée.

2. Tester les routes et leur contenu

• Sur la page d’accueil, vérifiez la présence de l’introduction et des deux cartes forêt et montagne.
• Ouvrez le lien de la forêt : l’URL doit être `/itineraires/foret`, et la page doit présenter le bon nom, la description, la distance, la durée et le visuel.
• Revenez à l’accueil, puis répétez le contrôle pour la montagne à l’URL `/itineraires/montagne`.
• Depuis chaque page de détail, activez « Retour au catalogue » et vérifiez que vous retrouvez la liste.
• Saisissez directement une URL avec un slug qui n’existe pas, par exemple `/itineraires/inconnue` : le message prévu pour une route introuvable doit s’afficher.

Le test direct de l’URL est important : il vérifie aussi que la route dynamique fonctionne sans passer par la page d’accueil. Pour chaque détail, comparez le texte et l’image à l’itinéraire demandé. Une page qui s’ouvre mais affiche les données de l’autre randonnée signale généralement une incohérence entre le slug reçu et la donnée sélectionnée.

3. Contrôler l’affichage et les erreurs

Sur chaque route, vérifiez que l’en-tête, la navigation et le pied de page restent présents, puisque ces éléments appartiennent au layout partagé. Assurez-vous que la zone de contenu ne masque pas ces éléments et que les images forêt et montagne se chargent sans icône d’image cassée. Relisez également les textes alternatifs : ils doivent décrire le visuel correspondant plutôt que répéter un nom générique.

Ouvrez les outils de développement du navigateur et consultez la console après avoir parcouru les routes. Une erreur rouge peut révéler un problème que la mise en page ne rend pas évident ; une requête d’image échouée aide à isoler un chemin incorrect. Consultez aussi le terminal, où les erreurs de TypeScript, de compilation ou de route peuvent être plus détaillées.

4. Vérifier les conventions du projet

Avant de terminer, comparez les fichiers modifiés à l’arborescence attendue : app/layout.tsx, app/page.tsx, app/itineraires/[slug]/page.tsx, style.css et les deux images locales. Le layout doit importer l’unique feuille de style ; les liens de navigation utilisent Link et les visuels Image. Vérifiez que vous n’avez pas ajouté de classes, de variables CSS ou de styles inline hors du contrat du projet.

Si un contrôle échoue, corrigez une seule cause à la fois, puis rechargez la route concernée et refaites le parcours complet. Terminez par une vérification de compilation sans erreur dans le terminal. Une correction locale peut en effet modifier une donnée partagée par la page d’accueil et les détails ; il faut donc repasser par les deux itinéraires après toute modification.

À retenir

• Testez l’accueil, chaque détail, le lien de retour et une URL inconnue.
• Comparez pour chaque slug l’URL, le contenu et l’image affichés.
• Contrôlez les erreurs du terminal et de la console du navigateur.
• Confirmez que le layout, les fichiers, les classes et les styles respectent le contrat du projet.
• Après chaque correction, rejouez le parcours complet et vérifiez la compilation.

Votre catalogue est prêt lorsque ces contrôles passent pour les deux itinéraires et pour une route inconnue, sans erreur de compilation ni anomalie visible dans la console.