Una prueba de correo electrónico automatizada necesita más que una dirección de bandeja de entrada. Necesita un contrato que describa a qué mensaje pertenece la ejecución, cuánto tiempo esperar y qué evidencia conservar cuando la prueba falla.
Da a cada ejecución un registro de correlación
Almacena un identificador de ejecución de prueba, destinatario sintético, hora de activación y propósito esperado del mensaje. Cuando tu aplicación lo permita, incluye un marcador de correlación no sensible en el mensaje de prueba. Haz la coincidencia con más que solo el asunto: un mensaje antiguo con el mismo asunto de otro modo puede hacer que una ejecución fallida parezca exitosa.
Espera dentro de un presupuesto explícito
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 errorEsto es pseudocódigo, no un ejemplo de la API de CleanTempMail. Usa la documentación de la API actual para autenticación, puntos finales y límites de solicitud. Respeta las instrucciones de reintento y cancela el trabajo restante cuando el trabajo finalice.
Asegura el comportamiento después de la recepción
En un entorno de pruebas que controles, confirma que la acción de verificación produce el estado de cuenta previsto. Recibir un mensaje solo no prueba que su enlace funcione. Mantén los tokens de autenticación y los cuerpos de los mensajes fuera de la salida ordinaria de CI.
Haz que las fallas sean diagnosticables
Distingue entre fallo de envío de la aplicación, ausencia de mensaje coincidente antes de la fecha límite, indisponibilidad del proveedor y falla de aserción. Conserva marcas de tiempo e identificadores saneados, luego elimina las cuentas sintéticas y los artefactos de correo según la política de retención de pruebas del equipo.