Historia del asunto:
La automatización de las pruebas de notificaciones por correo electrónico se ha vuelto relevante con el desarrollo de sistemas de aviso (por ejemplo, al registrarse, cambiar la contraseña, recordatorios). Inicialmente, estas pruebas se realizaban manualmente y se verificaban a través del correo real (lo cual es extremadamente ineficiente y poco seguro en CI/CD). Luego aparecieron herramientas especializadas (MailHog, Mailtrap, servidores SMTP falsos), que hicieron posible y segura la automatización.
Problema:
Las principales complejidades están relacionadas con el hecho de que el correo electrónico se envía "fuera" del sistema, lo que significa que es necesario: a) interceptar el envío, b) asegurarse del contenido del correo, c) verificar la corrección del envío (formato de encabezados, presencia de adjuntos, enlaces, i18n, correcta correspondencia con los eventos en el sistema). Se añaden complicaciones relacionadas con la velocidad de entrega, la limpieza de las bandejas entre las pruebas, y el manejo de errores SMTP.
Solución:
Utilizar servicios especiales de interceptación de correos: Mailtrap, MailHog, o servidores SMTP falsos integrados que no entregan correos en la bandeja real, sino que los mantienen en una "cesta" de prueba.
Integrar el trabajo con estas herramientas a través de un marco API o wrappers REST y realizar la espera de correos, comprobar los parámetros clave del correo, validar los adjuntos, y la presencia de enlaces correctos.
Generar correos únicos para las pruebas, aislar los datos de prueba (por ejemplo, usar un dominio de prueba) y limpiar las bandejas antes de cada ejecución de prueba automática.
Comprobar no solo el cuerpo del correo, sino también la funcionalidad de los enlaces, el envío desde diferentes SMTP, y la correcta visualización para diferentes locales y formatos.
Características clave:
¿Se pueden probar las notificaciones por correo enviando correos a bandejas de correo normales en gmail/yandex y verificándolos a través de IMAP?
No, eso se hace a menudo, pero este enfoque es poco confiable (dependencia del funcionamiento del servicio de correo externo, filtros de spam, no hay aislamiento entre pruebas, complicaciones para limpiar la bandeja, no se garantiza la entrega).
¿Es suficiente comprobar solo que el correo ha llegado?
No, hay que validar el cuerpo, los adjuntos, la presencia de los enlaces necesarios, la plantilla de idioma correcta, y la coincidencia de los encabezados (From/To/Subject), y la corrección de la estructura mime.
¿En la prueba se puede no limpiar la bandeja falsa entre los escenarios, no pasará nada malo?
¡No! Si no se limpia la bandeja entre las pruebas, rápidamente habrá confusión y será imposible identificar los errores. Los escenarios "verán" correos ajenos, y las pruebas se volverán inválidas.
Las pruebas de correo se construyeron a través de un gmail de prueba, se inició sesión a través de IMAP, y solo se comprobó que "algo llegó" a la bandeja. El correo a menudo caía en spam, parte de los correos no llegaba, y tras lanzar pruebas paralelas en una misma bandeja, analizar los correos se volvió imposible.
Pros:
Contras:
Se implementó Mailtrap, se asignaron bandejas únicas para cada caso de prueba, se implementó limpieza automática, validación de contenido y adjuntos, tiempo de espera, y comprobaciones por idioma.
Pros:
Contras: