Pourquoi les e-mails de vérification sont difficiles à tester
L’inscription est la première chose que fait chaque utilisateur, et l’e-mail de confirmation est le premier message que votre application lui envoie. C’est aussi l’un des parcours les plus difficiles à bien tester :
- Chaque exécution demande une nouvelle adresse. Réutilisez-en une et vous obtenez « cet e-mail est déjà enregistré » ; les testeurs finissent par inventer des adresses ou supprimer des comptes entre les exécutions.
- Les boîtes de réception partagées mélangent tout. Avec un Gmail d’équipe, les e-mails de confirmation de cinq personnes arrivent au même endroit. Quelqu’un clique sur votre lien, ou vous utilisez un code destiné à un autre.
- Les adresses avec + ne sont pas ce que tapent les vrais utilisateurs. Des adresses comme
name+test1@gmail.comsont rejetées ou discrètement normalisées par certains formulaires d’inscription : le parcours testé n’est pas celui de vos utilisateurs. - Les capteurs de courrier locaux s’arrêtent à votre ordinateur. Des outils comme Mailpit ne voient que le courrier envoyé par votre stack locale. Ils ne peuvent pas dire si les e-mails de staging ou de production sont vraiment délivrés, ni vers quoi ils pointent.
Comment cela fonctionne avec Proxy Mail QA
- Créez une adresse. Un clic vous donne une adresse aléatoire et impossible à deviner, comme
k3f9q2m8x7aa@mailclub.dev. Vous pouvez aussi choisir un nom personnalisé, ou créer tout un lot, chacune avec un nom et un nom d’utilisateur générés pour le formulaire d’inscription. - Inscrivez-vous dans l’application testée. Utilisez l’adresse exactement comme un vrai utilisateur.
- Regardez la ligne se mettre à jour. En quelques secondes, la vue Comptes affiche l’expéditeur et l’action de l’e-mail : boutons Ouvrir le lien et Copier le lien pour un lien, ou le code avec un bouton Copier.
- Vérifiez l’e-mail lui-même. Ouvrez la boîte de réception pour lire le message complet, avec les images distantes bloquées jusqu’à ce que vous les autorisiez, et tous les codes et liens qui y ont été trouvés.
Rien de notre côté n’ouvre ni ne précharge les liens de vos e-mails : un lien de vérification à usage unique reste donc inutilisé quand vous cliquez dessus.
Ce qu’il faut vérifier dans un e-mail de vérification
Un e-mail de confirmation peut « fonctionner » et être quand même cassé. Parcourez cette liste dans chaque environnement :
- Il arrive en quelques secondes, avec un nom d’expéditeur que vos utilisateurs reconnaîtront.
- Le lien ouvre le bon environnement. Un lien vers
localhost:3000depuis le staging est un bug, et nous le signalons. - Le lien fonctionne exactement une fois. Un deuxième clic affiche un message utile, pas une page d’erreur.
- Un lien expiré explique quoi faire ensuite, et Resend en envoie un nouveau.
- L’objet et la première phrase ont du sens dans une boîte de réception chargée, et il existe une version en texte brut.
- Après confirmation, l’utilisateur arrive à un endroit logique et est connecté (ou invité à se connecter).
Garder la trace de chaque compte de test
Chaque adresse garde ses propres notes, tags et persona généré, ainsi que le mot de passe utilisé à l’inscription, chiffré et masqué jusqu’à ce que vous l’affichiez. Des semaines plus tard, vous retrouvez encore « le compte jeune en staging » en cherchant dans les notes ou les tags, au lieu de deviner de quel alias Gmail il s’agissait.