Centre de connaissances développeurs & QA
E-mail temporaire pour développeurs et QA
Utilisez des boîtes temporaires isolées pour tester inscriptions, OTP, liens magiques et réinitialisations sans transformer une boîte personnelle partagée en infrastructure de test.
Les tests e-mail échouent souvent pour des raisons banales : une ancienne adresse réutilisée, un OTP précédent pris pour le nouveau, un lien qui pointe vers le mauvais environnement ou plusieurs tests mélangés dans la même boîte. Ce cluster se concentre sur la conception du test et ce que l’utilisateur reçoit réellement. Une boîte web classique ne remplace pas une API de test dédiée lorsque la CI exige des assertions programmatiques.
Chaque guide traite un mode d’échec précis au lieu de répéter le même cas d’usage générique.
Testez le parcours réellement reçu par l’utilisateur
Commencez par isoler le scénario. Vérifiez ensuite le message, le code ou le lien, l’environnement visé et le nettoyage nécessaire avant le prochain test.
Tester les flux e-mail avec des boîtes temporaires sans créer de bruit de test
Utilisez un destinataire neuf pour observer le message réellement reçu, puis séparez livraison, contenu, environnement et état final afin de diagnostiquer chaque panne.
Lire le guideTester la vérification e-mail d'une inscription jusqu'à l'état vérifié
Traitez la vérification d'inscription comme une transition d'état : nouvelle adresse, message courant, action de vérification puis compte réellement marqué comme vérifié.
Lire le guideTester les OTP par e-mail sans accepter le mauvais code
Testez les OTP autour de la récence, du renvoi, de l'expiration, des tentatives et de l'état créé après le bon code, pas autour d'un simple nombre trouvé dans la boîte.
Lire le guideTester les magic links sans manquer les bugs de session
Contrôlez le destinataire, l'environnement, le comportement du lien, la redirection et surtout la session authentifiée créée après l'ouverture du magic link.
Lire le guideTester les e-mails de réinitialisation comme un flux de sécurité complet
Suivez la demande, le token, le changement de mot de passe, le replay et l'état de connexion final au lieu de limiter le test à l'arrivée du message.
Lire le guidePourquoi les tests E2E e-mail ont besoin de boîtes isolées en CI parallèle
Donnez à chaque scénario ou worker son propre destinataire pour empêcher les exécutions parallèles de lire, invalider ou nettoyer les messages des autres.
Lire le guidePolling ou temps réel pour les tests e-mail : choisissez une attente, pas une garantie de livraison
Polling et événements temps réel modifient la façon dont le test découvre un message reçu ; ils ne garantissent pas le délai du sender, de la file ou du transport SMTP.
Lire le guidePourquoi les boîtes de test partagées rendent la QA e-mail instable
Une boîte commune crée un état caché entre humains, retries, environnements et tests parallèles ; rendez la propriété du destinataire explicite.
Lire le guide