Tester le parcours complet du carnet

Un formulaire qui semble fonctionner ne garantit pas que le carnet est sûr ni que ses données restent cohérentes. Vous allez vérifier le parcours réel, depuis une session anonyme jusqu’à la déconnexion, et tester les erreurs courantes avant de considérer le carnet comme terminé.

Les leçons précédentes ont établi le contrôle d’accès, la validation serveur, le jeton CSRF et les redirections après écriture. Ici, vous ne remplacez pas ces mécanismes : vous les éprouvez dans les pages du projet et vérifiez que les résultats correspondent aux règles attendues.

Préparer une vérification reproductible

Utilisez l’environnement local et les fichiers du carnet déjà en place. Avant les essais, faites une copie de sauvegarde du fichier JSON, notez les contacts présents et vérifiez que vous connaissez le mot de passe de test. Une sauvegarde vous permet de restaurer les données après les essais de modification et de suppression.

Pour chaque scénario, notez l’action, le résultat attendu et le résultat observé. Un test est réussi si la page, le stockage et l’état de session concordent ; un message visuellement correct ne suffit pas si, par exemple, une suppression a aussi modifié un autre contact.

Tester la connexion et les accès privés

• Ouvrez une fenêtre privée ou effacez les cookies du site, puis demandez directement index.php. Le serveur doit refuser l’accès et rediriger vers la page de connexion, sans afficher la liste des contacts.
• Essayez de vous connecter avec un mot de passe incorrect, puis avec le bon. Le premier essai doit laisser la session non authentifiée et afficher une erreur exploitable ; le second doit ouvrir le carnet.
• Après connexion, ouvrez index.php, contact-ajouter.php, contact-modifier.php et contacts-rechercher.php. Vérifiez que les pages accessibles selon leur rôle s’affichent sans redemander la connexion.
• Dans un onglet distinct, supprimez le cookie de session et rechargez une page privée. L’accès doit être refusé : une adresse connue ou un ancien lien ne remplace pas une session authentifiée.

Parcourir les opérations du carnet

Une fois connecté, vérifiez d’abord la liste avec plusieurs contacts, puis avec une recherche correspondante et une recherche sans résultat. Le terme recherché doit rester dans le champ et les résultats doivent inclure uniquement les contacts attendus ; une recherche ne doit jamais modifier le fichier de stockage.

Ajoutez ensuite un contact de test avec un nom, une adresse e-mail et un téléphone. Vérifiez sa présence après la redirection et rechargez la liste : le contact doit rester enregistré sans que le navigateur propose de répéter la soumission. Modifiez ce contact et contrôlez que son identifiant reste le même et que les autres entrées n’ont pas changé.

Testez la suppression uniquement sur le contact de test. Vérifiez la confirmation prévue par la page, puis contrôlez que le contact a disparu et que les autres sont toujours présents. Enfin, répétez les opérations sans jeton CSRF valide, si vous pouvez préparer cette soumission avec les outils de développement : aucune écriture ne doit être effectuée.

Vérifier les cas limites des formulaires

Pour l’ajout et la modification, envoyez un formulaire vide, puis testez séparément un nom absent, un nom trop long, une adresse e-mail mal formée et des espaces autour des valeurs. La validation serveur doit refuser les données invalides, associer une erreur au champ concerné et conserver les valeurs saisies sans les interpréter comme du HTML.

Testez aussi un identifiant de modification inexistant, un identifiant de suppression absent et un identifiant transmis sous un format inattendu. Le serveur doit traiter ces cas comme des erreurs maîtrisées : aucun contact ne doit être modifié ou supprimé par défaut, et aucun détail technique ne doit apparaître dans la page.

Terminer la session et diagnostiquer un échec

Cliquez sur « Se déconnecter », puis essayez de revenir à index.php avec le bouton précédent et en saisissant directement son adresse. Les pages privées doivent à nouveau refuser l’accès. La déconnexion doit invalider l’état d’authentification côté serveur ; masquer un lien ou rediriger sans terminer la session ne suffit pas.

Si un test échoue, reproduisez-le une fois et localisez l’étape fautive : réception de la requête, validation, contrôle d’accès ou CSRF, écriture, redirection, puis rendu. Contrôlez le code de réponse et les journaux PHP côté serveur, sans exposer les erreurs internes à l’utilisateur. Après correction, rejouez le scénario qui échouait et les scénarios voisins pour éviter une régression.

À retenir

• Testez le carnet comme une personne anonyme, puis authentifiée, et vérifiez que chaque page privée contrôle l’accès côté serveur.
• Parcourez recherche, ajout, modification et suppression en contrôlant à la fois les messages et les données réellement conservées.
• Soumettez des valeurs absentes, invalides et des identifiants inconnus ; une erreur ne doit jamais provoquer une écriture inattendue.
• Après la déconnexion, les pages privées doivent rester inaccessibles, y compris avec une ancienne adresse ou le bouton précédent.