La versión poco fiable de una prueba de correo es corta: crear una dirección, dormir cinco segundos, leer el primer mensaje y esperar que pertenezca a esta ejecución.
La versión confiable sigue siendo simple, pero trata la entrega como asíncrona. Crea una dirección única, registra una hora de inicio, sondea dentro de una fecha límite, coincide con el mensaje previsto, valida la acción del producto y reporta suficiente contexto cuando algo falla.
Mantén la clave API fuera de la URL
Envía la clave GPTMail en el encabezado X-API-Key. No la pongas en los parámetros de consulta ?api_key=. Las URLs se almacenan rutinariamente en el historial del navegador, registros de acceso, sistemas de monitoreo y datos de referer.
X-API-Key: YOUR_API_KEYAlmacena la clave en el gestor de secretos de tu CI y enmascara su aparición en los registros. Una clave pública diaria es conveniente para la exploración; los suites automatizados controlados deben usar una clave cuya cuota y uso puedas rastrear.
Los endpoints actuales y ejemplos de respuesta se mantienen en la página de documentación de la API de GPTMail.
Una dirección por ejecución
Genera una nueva dirección para cada prueba ejecutable de forma independiente. No derives la corrección de una bandeja de entrada compartida por todo el conjunto de pruebas.
Registra la dirección, ID del escenario, entorno y hora de inicio de la prueba. Estos valores te permiten rechazar mensajes obsoletos y diagnosticar colisiones sin registrar secretos del mensaje.
Sondea contra una fecha límite, no contra una pausa fija
El tiempo de entrega del correo varía. Una pausa fija de cinco segundos es tanto un desperdicio cuando la entrega es rápida como inestable cuando es lenta.
Usa un bucle limitado:
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)La fecha límite pertenece al contrato de la prueba. Un flujo de restablecimiento de contraseña puede necesitar un límite diferente al de una vista previa de boletín masivo. Mantén el límite explícito para que una dependencia lenta no alargue silenciosamente todo el trabajo de CI.
Coincide con precisión
“Primer mensaje en la bandeja de entrada” no es un selector útil. Coincide varios señales:
- el destinatario es igual a la dirección creada para esta ejecución;
- la hora de creación es posterior a la hora del disparador;
- el remitente pertenece al servicio esperado;
- el asunto o tipo de mensaje coincide con el flujo;
- el ID del mensaje no ha sido consumido previamente.
Cuando el remitente puede emitir varios códigos, selecciona el mensaje más reciente que coincida. Conserva su ID en la salida de la prueba para que los reintentos no lo reutilicen accidentalmente.
Lee solo después de una coincidencia en la lista
La enumeración de la bandeja de entrada debe ser el paso de descubrimiento barato. Obtén el mensaje completo solo para el candidato seleccionado. Esto reduce trabajo innecesario y evita analizar correos promocionales no relacionados.
Valida el resultado del negocio, no solo la presencia de una cadena de seis dígitos. Envía el código o abre el enlace esperado, luego afirma que la cuenta alcanza el estado correcto.
Maneja los límites de velocidad como una señal
Si la API devuelve una respuesta de cuota o límite de velocidad, detén el intento actual y muestra la información de reinicio. Los reintentos agresivos convierten una señal clara de capacidad en ruido y pueden retrasar pruebas no relacionadas.
Limita la concurrencia en el ejecutor de pruebas, especialmente cuando un suite crea muchas direcciones a la vez. Un pequeño pool de trabajadores es más fácil de depurar que cientos de bucles de sondeo simultáneos.
Limpieza sin ocultar fallos
La limpieza debe ejecutarse después de capturar la evidencia. En caso de éxito, elimina los mensajes o permite que la retención corta los maneje. En caso de fallo, conserva la dirección y el ID del mensaje en artefactos protegidos del CI el tiempo suficiente para la investigación, luego elimínalos.
Nunca imprimas códigos de verificación, enlaces privados o cuerpos HTML completos en los registros públicos de compilación.
Haz que los reintentos sean idempotentes
Reintenta la prueba como una nueva ejecución con una nueva dirección. No asumas que repetir la misma solicitud contra la misma cuenta y bandeja de entrada parte de un estado limpio. El remitente puede invalidar códigos antiguos, limitar solicitudes repetidas o rechazar invitaciones duplicadas.
Si una solicitud de red se agota, distingue “no se recibió respuesta” de “la operación no ocurrió”. Verifica el estado observable antes de emitir un reintento destructivo.
Reporta el punto de fallo
Un fallo útil de automatización identifica una de estas etapas:
- falló la generación de la dirección;
- falló la acción del producto antes de encolar el correo;
- no llegó ningún mensaje coincidente antes de la fecha límite;
- el mensaje llegó pero su contenido no coincidió;
- falló la acción de verificación;
- falló la limpieza.
Esta clasificación convierte un “la prueba de correo falló” intermitente en un trabajo que un equipo puede asumir.
Para la matriz de pruebas más grande, lee Un plan real de pruebas de correo. Para diagnóstico de entrega, usa Correo de verificación no llega: encuentra el paso roto.