Mail fake pour les tests : des adresses sûres pour les formulaires d’inscription
Si vous créez ou testez des sites, vous tapez sans arrêt des adresses e-mail dans des formulaires. La seule chose qui ne doit jamais arriver, c’est qu’un message de test atterrisse dans la vraie boîte d’un inconnu. Cette page indique quel mail fake utiliser pour chaque type de test — et quand le message doit vraiment arriver.
Décidez d’abord si le courrier doit arriver
Cette seule question décide de tout, et elle mérite d’être posée explicitement, car la réponse est « non » plus souvent qu’on ne le croit.
| Ce que vous testez | Le courrier doit-il arriver ? | Utilisez |
|---|---|---|
| Validation, stockage ou affichage d’une adresse | non | un domaine réservé — voir plus bas |
| Le parcours de confirmation, à la main | oui | une boîte d’ici |
| Le parcours de confirmation, automatisé | oui, lisible par du code | un service avec une API |
| Tests de charge ou de volume | non — et il ne le doit pas | toujours un domaine réservé |
Quand le courrier ne doit pas arriver : des noms réservés
Des domaines existent précisément pour cela et ne seront jamais à personne : example.com et ses frères example.net et example.org, réservés par la RFC 2606, plus toute l’extension .test.
Les adresses sur ces domaines sont la bonne réponse pour les données d’exemple, les jeux de départ et les tests de charge. Rien de ce que vous envoyez ne peut atteindre une personne, puisqu’il n’y a personne — par accord international, pas par chance.
test@mycompanytest.com se révèle assez souvent être le vrai domaine de quelqu’un, et un test de charge dirigé dessus ne se distingue pas d’une attaque. Les noms réservés ne coûtent rien et suppriment toute cette catégorie d’accidents.Quand le courrier doit arriver, à la main
Prenez une adresse ici, lancez le parcours et lisez ce que votre application a réellement envoyé — en-têtes, liens, et l’allure du message quand ce n’est pas votre propre logiciel de messagerie qui l’affiche. Deux choses que cela révèle, et qu’un capteur de courrier local ne voit pas :
- La vraie livraison. Le message emprunte un vrai chemin de courrier : un expéditeur mal configuré échoue ici, pas en production.
- Ce qu’en voit un inconnu. Des liens qui ne marchent que dans votre session, des images qui ne se chargent jamais, un lien de désabonnement qui pointe vers localhost — tout saute aux yeux.
Surveillez aussi les avertissements de pièces jointes si votre application envoie des fichiers : ce sont les mêmes que verront vos utilisateurs.
Quand il faut automatiser
Récupérer la page par script à la place est un mauvais calcul, même quand ça marche : c’est fragile, non documenté, et c’est exactement le type de trafic qui finit par être bloqué.
Tester les cas de refus
Les échecs intéressants ne sont pas « une adresse valide fonctionne ». À couvrir :
- Une adresse sur un domaine sans enregistrement MX — la livraison échoue alors que l’adresse est bien formée. Votre code devrait distinguer les deux. Vérifiez lequel est lequel.
- Un domaine internationalisé, sous sa forme Unicode comme sous sa forme
xn--. La plupart des validateurs rejettent l’une et acceptent l’autre, et généralement dans le mauvais sens — convertisseur. - Les variantes Gmail avec points et plus. Si votre contrôle d’unicité compare les chaînes brutes, une même personne peut créer des comptes sans limite. Normalisez d’abord — cette page fait exactement ce que votre contrôle devrait faire.
- Une partie locale très longue. La norme autorise 64 caractères ; bien des formulaires coupent en silence à 20 et enregistrent une adresse qui ne mène plus nulle part.
À construire, pas à tester
Si votre produit refuse les adresses de mail fake, refusez-les clairement. « E-mail invalide » pour une adresse parfaitement valide est l’erreur la plus déroutante du genre : l’utilisateur vérifie l’orthographe, retape, et reçoit le même message. « Nous n’acceptons pas les adresses de mail fake » prend la même place et met fin à la confusion.