Vérifier le fonctionnement de bout en bout

Une page qui s’affiche une fois ne suffit pas à valider un parcours relié à une base. Vous devez également vérifier ce qui se passe quand une recherche ne trouve rien, quand une randonnée n’existe pas ou quand le service de données échoue.

Dans cette leçon, vous allez parcourir l’application comme un utilisateur, puis vérifier les états attendus et l’absence de données sensibles dans le navigateur. Les pages et l’action serveur sont déjà assemblées ; vous ne modifiez ni leur structure ni la feuille de style.

Préparer une vérification reproductible

Démarrez l’application avec la commande de développement déjà configurée dans votre projet, puis ouvrez-la dans un navigateur. Vérifiez d’abord que la configuration serveur requise est disponible dans l’environnement local, sans copier sa valeur dans un fichier accessible au navigateur ni dans un message de diagnostic partagé.

Utilisez des données de test dont vous connaissez les difficultés, les identifiants et les avis. Pour vérifier le cas vide et les erreurs, préparez aussi des conditions de test contrôlées : un filtre sans correspondance, un identifiant inconnu et, si votre environnement de test le permet, une indisponibilité temporaire du service de données. Ne provoquez pas une panne sur une base de production.

Parcourir le catalogue et la fiche

Commencez par la route / sans filtre. Vérifiez que le titre, le formulaire de difficulté et les cartes correspondent aux données renvoyées par le service. Ouvrez une randonnée depuis une carte : son identifiant doit conduire à une fiche dont le nom, la description, la difficulté et la distance correspondent à l’enregistrement choisi.

Sélectionnez ensuite une difficulté et envoyez le formulaire. Le filtre doit être visible dans l’URL, rester sélectionné après le chargement et ne laisser apparaître que les randonnées correspondantes. Essayez une difficulté valide qui ne retourne aucun enregistrement : la page doit annoncer clairement l’absence de résultat, sans afficher une erreur de chargement. Revenez au filtre neutre et confirmez que le catalogue complet réapparaît.

Sur une fiche sans avis, vérifiez que le message d’absence d’avis apparaît tout en laissant le formulaire disponible. Ouvrez aussi une URL de détail avec un identifiant inexistant : la ressource doit être signalée comme introuvable, et non remplacée par une fiche vide. Ces contrôles s’appuient sur la distinction entre liste vide, erreur et ressource absente déjà établie dans les leçons précédentes.

Tester le dépôt d’un avis et les erreurs

Sur une fiche existante, publiez un avis de test reconnaissable. Après la réussite, vérifiez que l’avis apparaît sur la fiche actualisée et qu’il est rattaché à la bonne randonnée. Rechargez la page pour confirmer qu’il provient bien des données enregistrées et qu’il ne s’agissait pas seulement d’un changement temporaire dans l’interface.

Essayez ensuite d’envoyer un formulaire sans texte. Le navigateur doit empêcher l’envoi grâce au champ obligatoire ; la validation côté serveur reste néanmoins nécessaire, car une requête peut être construite en dehors du formulaire. Dans un environnement de test, contrôlez également qu’un échec d’écriture ne produit pas un faux avis ni une confirmation de succès, et qu’il est traité comme une erreur plutôt que comme une absence de données.

Enfin, testez les états de chargement et d’erreur du catalogue et d’une fiche. Les fichiers app/loading.tsx et app/randonnees/[id]/loading.tsx doivent afficher un message adapté pendant l’attente ; les frontières d’erreur correspondantes doivent proposer la nouvelle tentative prévue. Un état de chargement peut être bref : si vous ne le voyez pas lors d’un chargement rapide, vérifiez-le avec une réponse de test temporairement ralentie, sans conserver cette simulation dans le parcours normal.

Contrôler la confidentialité et la cohérence

Dans les outils de développement du navigateur, inspectez les requêtes réseau, le HTML reçu et les ressources JavaScript chargées. Vérifiez qu’aucune clé d’API, adresse privée de base ou donnée interne de configuration n’est transmise au navigateur. La présence d’une URL de page ou des données nécessaires à son affichage n’autorise pas l’exposition des secrets : l’accès aux données doit rester effectué côté serveur.

• Catalogue non filtré : les randonnées disponibles s’affichent.
• Filtre valide : l’URL et les résultats correspondent ; filtre sans correspondance : un état vide apparaît.
• Fiche connue, inconnue ou sans avis : chaque cas présente l’état approprié.
• Avis accepté : l’écriture réussit et la fiche revalidée affiche l’avis ; échec : aucun faux succès.
• Chargement, erreur et secrets : chaque route conserve ses états dédiés et aucune clé privée n’est visible côté navigateur.

À retenir

• Testez chaque parcours avec des données dont vous connaissez le résultat attendu.
• Ne confondez pas résultat vide, ressource introuvable et erreur du service.
• Après un avis accepté, vérifiez l’enregistrement puis l’affichage actualisé de la fiche.
• Contrôlez les états de chargement et d’erreur sur le catalogue comme sur les fiches.
• Inspectez les échanges du navigateur pour repérer toute exposition de secret.