Vérifier le parcours complet et corriger les défauts

Un carnet peut sembler fonctionner tout en laissant passer une action sans connexion, en perdant une recherche après une modification ou en affichant une valeur saisie comme du HTML. Pour éviter ces défauts, vérifiez le parcours complet avec des données contrôlées, puis rattachez chaque anomalie à la couche qui en est responsable. Vous allez aussi vérifier qu’une correction ne casse pas les autres opérations.

Préparer un parcours de test reproductible

Utilisez une base de test distincte de vos données personnelles. Vérifiez que la configuration PHP et MySQL est chargée, que la table des contacts existe et que le hachage attendu est défini. Préparez un mot de passe de test, un contact reconnaissable et un navigateur dans lequel vous pouvez supprimer les cookies de session entre deux scénarios.

• Ouvrez le carnet dans une session sans cookie : la page privée ne doit pas révéler la liste des contacts.
• Envoyez un mot de passe incorrect : la connexion échoue et aucun état authentifié ne reste en session.
• Connectez-vous avec le mot de passe correct : la liste privée devient accessible et la navigation propose la déconnexion.
• Ajoutez un contact, puis vérifiez qu’il apparaît dans la liste avec ses champs exacts.
• Modifiez ce contact, recherchez-le avec une partie de son nom ou de son courriel, puis supprimez-le.
• Déconnectez-vous et rechargez la page privée : l’accès doit de nouveau être refusé.

Pour chaque étape, notez l’action, le résultat attendu et le résultat observé. Une fois le parcours normal validé, répétez les opérations avec un identifiant inexistant, un identifiant mal formé, un nom vide et des champs facultatifs laissés vides. Un défaut reproductible est plus facile à localiser qu’un message vague comme « la page ne marche pas ».

Tester les limites et la sécurité de l’affichage

Saisissez dans le nom une valeur contenant des caractères significatifs pour HTML, par exemple `alert(1)`, puis enregistrez le contact. La liste doit afficher le texte comme une valeur ordinaire, sans exécuter de script ; si le balisage apparaît dans la page, vérifiez l’échappement dans le gabarit concerné. Contrôlez également qu’une chaîne de recherche contenant des caractères tels que `%` ou `_` respecte le comportement prévu par la recherche du dépôt.

Essayez aussi d’accéder directement à une URL d’action privée sans être connecté et de soumettre une action POST après déconnexion. Le contrôle d’accès doit être effectué dans le point d’entrée avant l’appel au contrôleur de contacts. Masquer un lien dans la navigation ne protège pas une URL ou un formulaire envoyé manuellement.

Localiser et corriger un défaut

Suivez la donnée depuis son entrée jusqu’au résultat. Une action qui n’est pas reconnue relève du routage dans `public/index.php` ; une saisie acceptée à tort relève de la validation du contrôleur ou du modèle ; une ligne incorrecte relève de `ContactDepot` ou de la structure SQL ; une valeur affichée sans échappement relève du gabarit. Cette recherche par couche évite de corriger un défaut d’affichage en modifiant une requête SQL, ou l’inverse.

Si une soumission semble enregistrer deux fois une action, vérifiez que le contrôleur redirige après le traitement POST et que le point d’entrée termine la réponse après cette redirection. Si une page ne montre pas le message attendu, vérifiez d’abord les données transmises au gabarit et le chemin de rendu ; le gabarit doit afficher ces données, pas exécuter lui-même l’opération. Pour les erreurs SQL en environnement de développement, consultez les journaux serveur et évitez d’exposer les détails de connexion ou de requête à l’utilisateur.

Après chaque correction, rejouez le scénario qui a révélé le défaut, puis les opérations voisines : par exemple, après une correction du routage, testez la liste, l’ajout et la déconnexion. Cette répétition constitue un test de non-régression : elle confirme que la nouvelle version conserve les comportements déjà validés. Gardez une trace concise des résultats afin de pouvoir refaire la vérification après une évolution du carnet.

À retenir

• Parcourez connexion, opérations CRUD, recherche et déconnexion dans une base de test.
• Vérifiez aussi les saisies invalides, les identifiants absents et les valeurs contenant du HTML.
• Contrôlez l’accès dans le point d’entrée, même lorsque les liens privés ne sont pas affichés.
• Localisez chaque défaut dans sa couche, corrigez-le, puis rejouez les scénarios concernés.

Vous pouvez maintenant livrer le carnet en vous appuyant sur une grille de vérification qui couvre ses parcours normaux et ses limites.