Centro de conocimiento para desarrollo y QA
Correo temporal para desarrolladores y QA
Usa bandejas temporales aisladas para probar registros, OTP, enlaces mágicos y recuperación de contraseña sin convertir un buzón personal compartido en infraestructura de pruebas.
Muchos fallos de pruebas de correo no son misteriosos: se reutiliza una dirección antigua, se toma un OTP previo, un enlace apunta al entorno equivocado o dos ejecuciones comparten la misma bandeja. Este bloque trata de diseño de pruebas y del correo que recibe el usuario. Una bandeja web normal no sustituye una API de testing dedicada cuando CI necesita aserciones programáticas.
Cada guía cubre un modo de fallo concreto en lugar de repetir el mismo caso de uso genérico.
Prueba el flujo que recibe el usuario
Aísla primero el escenario. Después valida el mensaje, el código o enlace, el entorno correcto y la limpieza que deja la siguiente ejecución en un estado conocido.
Cómo probar flujos de email con bandejas temporales sin crear ruido de testing
Usa un destinatario nuevo para observar el mensaje real y separa entrega, contenido, entorno y estado final para que cada fallo tenga una causa diagnosticable.
Leer guíaCómo probar la verificación de email del registro hasta la cuenta verificada
Prueba el registro como transición de estado: dirección limpia, mensaje actual, acción de verificación y cuenta finalmente reconocida como verificada.
Leer guíaCómo probar OTP por email sin aceptar el código equivocado
Prueba recencia, reenvío, caducidad, intentos y estado final del OTP; no trates cualquier número reciente de la bandeja como evidencia suficiente.
Leer guíaCómo probar magic links sin perder errores de sesión
Comprueba destinatario, entorno, enlace, redirecciones e identidad de la sesión creada; un link visible no demuestra por sí solo que el login sea correcto.
Leer guíaCómo probar emails de restablecimiento como un flujo de seguridad completo
Sigue solicitud, token, cambio de contraseña, replay y login final; que el email llegue no demuestra que la recuperación sea segura.
Leer guíaPor qué los tests E2E de email necesitan bandejas aisladas en CI paralela
Da a cada escenario o worker un destinatario propio para que ejecuciones paralelas no consuman, invaliden o borren mensajes ajenos.
Leer guíaPolling vs realtime en tests de email: elige una espera, no una falsa garantía de entrega
Polling y eventos solo cambian cómo observas el inbox; no controlan cuándo el sender, la cola o SMTP entregan el mensaje.
Leer guíaPor qué los buzones de pruebas compartidos vuelven flaky el QA de email
Un mailbox común acopla personas, retries, entornos y ejecuciones paralelas; asigna propiedad explícita a cada destinatario o escenario.
Leer guía