Un test d’e‑mail automatisé nécessite plus qu’une adresse de boîte de réception. Il faut un contrat décrivant quel message appartient à l’exécution, combien de temps attendre et quelles preuves conserver lorsque le test échoue.
Donnez à chaque exécution un enregistrement de corrélation
Conservez un identifiant d’exécution de test, un destinataire synthétique, l’heure de déclenchement et l’objectif attendu du message. Lorsque votre application le permet, incluez un marqueur de corrélation non sensible dans le message de test. Effectuez la correspondance avec plus que le sujet seul : un ancien message ayant le même sujet pourrait sinon faire apparaître une exécution cassée comme réussie.
Attendez dans un budget explicite
create test context
trigger the application action
until the test deadline:
read messages using the provider's documented API
accept only a message matching this run
wait using bounded backoff if no match exists
report matched, timed out, or provider errorIl s’agit de pseudocode, pas d’un exemple d’API CleanTempMail. Utilisez la documentation de l’API actuelle pour l’authentification, les points de terminaison et les limites de requêtes. Respectez les instructions de nouvelle tentative et annulez le travail restant lorsque le job se termine.
Validez le comportement après réception
Dans un environnement de test que vous contrôlez, confirmez que l’action de vérification produit l’état de compte prévu. La simple réception d’un message ne prouve pas que son lien fonctionne. Gardez les jetons d’authentification et le corps des messages hors de la sortie CI ordinaire.
Rendez les échecs diagnostiquables
Distinguez l’échec d’envoi de l’application, l’absence de message correspondant avant la date limite, l’indisponibilité du fournisseur et l’échec d’assertion. Conservez les horodatages et identifiants assainis, puis supprimez les comptes synthétiques et les artefacts de messagerie selon la politique de rétention des tests de l’équipe.