Tester les emails de Better Auth avec InboxTap

Associer chaque fonction de rappel d’email

La vérification utilise emailVerification.sendVerificationEmail, la réinitialisation du mot de passe emailAndPassword.sendResetPassword, et les extensions de lien magique et d’OTP par email exposent sendMagicLink et sendVerificationOTP. Faites passer chaque fonction par le même expéditeur local afin que le test observe le modèle réellement construit par l’application.

Conservez sans modification l’URL ou l’OTP généré. Reconstruire une URL d’authentification dans le test peut masquer des erreurs de configuration dans les URL de rappel, les listes de redirections autorisées, l’encodage du jeton et les modèles.

• Documentation Better Auth sur les emails ↗
• Documentation Better Auth sur les liens magiques ↗
• Documentation Better Auth sur les OTP par email ↗

Envoyer par le transport local

Implémentez sendLocalEmail avec un transport Nodemailer configuré pour InboxTap : localhost, le port SMTP choisi, secure: false, ignoreTLS: true et aucun champ auth. Dans un test fondé sur une configuration injectée, transmettez inboxTap.smtp au lieu de recopier un port dynamique.

L’extrait renvoie la promesse de livraison afin de rendre les échecs déterministes dans un exemple local. Better Auth recommande un envoi en arrière-plan en production pour réduire les canaux auxiliaires temporels. Si vous suivez ce modèle, utilisez le mécanisme de tâche en arrière-plan pris en charge par la plateforme et laissez l’attente bornée d’InboxTap observer la fin de l’envoi.

const auth = betterAuth({
  emailVerification: {
    sendVerificationEmail: ({ user, url }) =>
      sendLocalEmail(user.email, "Verify your email", url),
  },
  emailAndPassword: {
    enabled: true,
    sendResetPassword: ({ user, url }) =>
      sendLocalEmail(user.email, "Reset your password", url),
  },
  plugins: [
    magicLink({
      sendMagicLink: ({ email, url }) =>
        sendLocalEmail(email, "Your sign-in link", url),
    }),
    emailOTP({
      sendVerificationOTP: ({ email, otp }) =>
        sendLocalEmail(email, "Your verification code", otp),
    }),
  ],
});

Traiter les liens comme des secrets

Créez un nouveau destinataire InboxTap pour le test, déclenchez l’opération Better Auth et attendez un lien grâce à un filtre stable de sujet ou de chemin. Avant de naviguer, analysez l’URL et vérifiez l’origine et le chemin de rappel attendus sans afficher son jeton.

Un lien magique peut créer un utilisateur par défaut. Activez disableSignUp lorsque le produit doit autoriser la connexion uniquement aux utilisateurs existants, puis couvrez explicitement les cas acceptés et refusés.

Respecter la configuration des OTP

L’extension d’OTP par email de Better Auth génère six chiffres par défaut, ce qui correspond au motif standard de waitForCode() dans InboxTap. Si otpLength ou generateOTP modifie le format, fournissez un motif propre au projet au lieu de supposer que tous les fournisseurs émettent six chiffres.

Pour tester un renvoi, attendez le second message complet en définissant afterId sur l’identifiant du premier, puis extrayez le nouveau code du message renvoyé. Cette méthode distingue les livraisons et permet au test applicatif de prouver si l’ancien code a été invalidé.

Couvrir le contrat du produit

La capture de l’email n’est que le milieu du parcours. Poursuivez et vérifiez l’état validé, la création de session, la destination de redirection, le traitement des jetons invalides ou expirés, la limite de tentatives et le remplacement du mot de passe selon la configuration de l’application.

Évitez de placer des secrets dans les noms de test, les journaux, les instantanés ou les captures d’écran. Les assertions d’InboxTap suppriment les valeurs porteuses de jetons, et le masquage de ses rapports reste une protection au mieux, pas une autorisation de publier des éléments d’authentification non relus.