Comment tester les parcours OTP par email

Consigner le contrat de l’OTP

Confirmez la longueur et l’alphabet du code, sa durée de validité, le nombre maximal de tentatives, la stratégie de renvoi et l’invalidation éventuelle du premier code par la demande d’un second. Ne présentez pas les six chiffres comme une norme universelle : Better Auth en produit six par défaut, mais reste configurable, et Supabase accepte des longueurs de six à dix chiffres.

Conservez la valeur sous forme de chaîne pendant tout le test. Une conversion numérique supprime les zéros initiaux et peut rendre impossible la saisie exacte d’un code pourtant valide.

• Options des OTP par email dans Better Auth ↗
• Longueur des OTP par email dans Supabase ↗

Capturer le premier code

Créez une boîte pour le test, déclenchez l’action d’envoi de code dans l’application, puis appelez waitForCode() avec un filtre de sujet. Son expression par défaut recherche une valeur de six chiffres dans le texte ou le HTML capturés ; fournissez une expression régulière ou une chaîne de motif lorsque l’application emploie un autre format.

Soumettez la chaîne renvoyée dans le véritable formulaire ou point de terminaison de vérification, puis contrôlez l’identité authentifiée et la session. Trouver des chiffres dans un email ne prouve pas à lui seul que le service dorsal accepte le bon code.

Distinguer un message renvoyé

Capturez le premier message complet et conservez son identifiant. Après avoir demandé un autre code, waitForMessage() avec afterId renvoie une livraison ultérieure ; extrayez le nouveau code de ce message précis, comme dans l’extrait.

N’utilisez pas waitForCode({ afterId }) pour cette assertion. Cette méthode commence par parcourir les messages existants afin de trouver une valeur correspondante : elle peut donc renvoyer l’ancien code avant que sa requête d’attente n’applique afterId. Attendre le second message rend la frontière de livraison explicite.

const firstEmail = await inbox.waitForMessage({
  subject: /code/i,
  timeoutMs: 20_000,
});

await requestAnotherCode();

const secondEmail = await inbox.waitForMessage({
  subject: /code/i,
  afterId: firstEmail.id,
  timeoutMs: 20_000,
});

const secondCode = secondEmail.text.match(/\b\d{6}\b/)?.[0];
expect(secondCode).toBeDefined();

Tester la rotation et la limite de tentatives

Lorsque la stratégie de renvoi configurée remplace les codes, prouvez que le premier échoue et que le second réussit. Si le fournisseur réutilise volontairement un code encore valide, vérifiez plutôt ce comportement. Ne transformez pas en garantie produit la valeur par défaut de la version installée.

Soumettez des valeurs invalides jusqu’à la limite configurée et confirmez que la tentative suivante est rejetée comme prévu. Appuyez cette assertion sur les réponses de l’application et l’état de session stocké : InboxTap n’implémente ni n’observe le compteur de vérifications du fournisseur.

Prendre en charge les codes longs et personnalisés

CapturedEmail.codes est un raccourci d’analyse pour les séquences uniques de quatre à huit chiffres. Un motif personnalisé de waitForCode() parcourt directement le corps du message : utilisez-le pour un code Supabase de neuf ou dix chiffres ou pour un format alphanumérique propre à l’application.

Restreignez assez l’expression régulière pour éviter les dates, les numéros d’assistance et les identifiants sans rapport présents dans le modèle. Un sujet stable associé à une délimitation propre au format est plus sûr que le choix de la première suite de chiffres.

Tester l’expiration avec une horloge maîtrisée

Préférez une horloge virtuelle prise en charge par le fournisseur, une source de temps injectée ou une courte durée réservée aux tests. Attendre toute la durée de production ralentit la suite sans supprimer les conditions de concurrence au voisinage de l’échéance.

Le code expiré doit échouer sans créer ni prolonger de session. La demande d’un nouveau code après l’expiration doit suivre la stratégie de renvoi documentée et produire une livraison distincte.

Éviter l’affichage des secrets

N’incluez pas l’OTP dans les noms de test, les messages d’assertion, les captures d’écran ou les journaux courants. Vérifiez sa forme et l’état applicatif obtenu au lieu de prendre un instantané du corps complet de l’email.

Si un livrable CI est nécessaire, utilisez le collecteur de rapports borné d’InboxTap avec des motifs de masquage propres au projet, puis relisez le résultat. La détection au mieux des jetons ne peut garantir que toutes les données personnelles ou secrètes personnalisées ont été trouvées.