La version peu fiable d'un test d'email est courte : créer une adresse, attendre cinq secondes, lire le premier message et espérer qu'il corresponde à cette exécution.
La version fiable reste simple, mais elle considère la livraison comme asynchrone. Elle crée une adresse unique, enregistre un horodatage de démarrage, interroge dans une limite de temps, fait correspondre le message prévu, valide l'action du produit et fournit suffisamment de contexte lorsqu'un problème survient.
Gardez la clé API hors de l'URL
Envoyez la clé GPTMail dans l'en-tête X-API-Key. Ne la placez pas dans les paramètres de requête ?api_key=. Les URL sont régulièrement stockées dans l'historique du navigateur, les journaux d'accès, les systèmes de surveillance et les données de référent.
X-API-Key: YOUR_API_KEYStockez la clé dans le gestionnaire de secrets de votre CI et masquez‑la dans les journaux. Une clé publique quotidienne est pratique pour l'exploration ; les suites automatisées contrôlées devraient utiliser une clé dont vous pouvez suivre le quota et l'utilisation.
Les points de terminaison actuels et les exemples de réponses sont maintenus sur la page de documentation de l'API GPTMail.
Une adresse par exécution
Générez une nouvelle adresse pour chaque test exécutable de façon indépendante. Ne déduisez pas la validité d'un test à partir d'une boîte partagée par l'ensemble de la suite de tests.
Enregistrez l'adresse, l'ID du scénario, l'environnement et l'heure de démarrage du test. Ces valeurs vous permettent de rejeter les messages obsolètes et de diagnostiquer les collisions sans consigner les secrets des messages.
Interroger jusqu'à une échéance, pas un sommeil fixe
Le temps de livraison des e‑mails varie. Un sommeil fixe de cinq secondes est à la fois gaspilleur lorsque la livraison est rapide et peu fiable lorsqu'elle est lente.
Utilisez une boucle bornée :
deadline = now + 90 seconds
delay = 2 seconds
while now < deadline:
messages = list inbox
candidate = newest message matching sender, subject, and start time
if candidate exists:
read candidate and continue the product test
wait delay with a small random jitter
delay = min(delay * 1.5, 10 seconds)L'échéance fait partie du contrat de test. Un flux de réinitialisation de mot de passe peut nécessiter une limite différente de celle d'un aperçu de newsletter en masse. Gardez la limite explicite afin qu'une dépendance lente n'étende pas silencieusement l'ensemble du job CI.
Correspondance précise
« Premier message dans la boîte de réception » n'est pas un sélecteur utile. Faites correspondre plusieurs signaux :
- le destinataire correspond à l'adresse créée pour cette exécution ;
- l'heure de création est postérieure à l'heure du déclencheur ;
- l'expéditeur appartient au service attendu ;
- l'objet ou le type de message correspond au flux ;
- l'ID du message n'a pas déjà été consommé.
Lorsque l'expéditeur peut émettre plusieurs codes, sélectionnez le message le plus récent correspondant. Conservez son ID dans la sortie du test afin que les nouvelles tentatives ne puissent pas le réutiliser accidentellement.
Lire uniquement après une correspondance de liste
Lister la boîte de réception doit être l'étape de découverte peu coûteuse. Récupérez le message complet uniquement pour le candidat sélectionné. Cela réduit le travail inutile et évite d'analyser des courriels promotionnels non pertinents.
Validez le résultat métier, pas seulement la présence d'une chaîne à six chiffres. Soumettez le code ou ouvrez le lien attendu, puis vérifiez que le compte atteint l'état correct.
Gérer les limites de débit comme un signal
Si l'API renvoie une réponse de quota ou de limitation de débit, arrêtez la tentative en cours et exposez les informations de réinitialisation. Des nouvelles tentatives agressives transforment un signal de capacité clair en bruit et peuvent retarder les tests non liés.
Limitez la concurrence dans le lanceur de tests, surtout lorsqu'une suite crée de nombreuses adresses simultanément. Un petit pool de travailleurs est plus facile à déboguer que des centaines de boucles d'interrogation simultanées.
Nettoyage sans masquer les échecs
Le nettoyage doit s'exécuter après la capture des preuves. En cas de succès, supprimez les messages ou laissez la rétention courte les gérer. En cas d'échec, conservez l'adresse et l'ID du message dans des artefacts CI protégés suffisamment longtemps pour l'enquête, puis supprimez‑les.
N'imprimez jamais les codes de vérification, les liens privés ou le corps HTML complet dans les journaux de construction publics.
Rendre les nouvelles tentatives idempotentes
Réessayez le test comme une nouvelle exécution avec une nouvelle adresse. Ne supposez pas que répéter la même requête contre le même compte et la même boîte démarre d'un état propre. L'expéditeur peut invalider les anciens codes, limiter les requêtes répétées ou rejeter les invitations en double.
Si une requête réseau dépasse le délai, distinguez « aucune réponse reçue » de « l'opération ne s'est pas produite ». Vérifiez l'état observable avant d'effectuer une nouvelle tentative destructive.
Signaler le point d'échec
Un échec d'automatisation utile identifie l'une de ces étapes :
- génération d'adresse échouée ;
- action du produit échouée avant l'envoi de l'email ;
- aucun message correspondant arrivé avant l'échéance ;
- le message est arrivé mais le contenu ne correspondait pas ;
- action de vérification échouée ;
- nettoyage échoué.
Cette classification transforme un « test d'email échoué » intermittent en un travail que l'équipe peut prendre en charge.
Pour la matrice de tests plus large, lisez Un véritable plan de test des e-mails. Pour le diagnostic de livraison, utilisez L'e-mail de vérification n'arrive pas : Trouver l'étape défaillante.