Prueba los flujos de cambio de correo electrónico sin perder enlaces
Cambiar el correo electrónico de una cuenta parece algo insignificante. Es una trampa común para los equipos de QA. Un tester actualiza una dirección. Otra persona abre el correo primero. Ahora el equipo discute sobre si la página de React está rota o si el enlace pertenecía al usuario equivocado.
Esta confusión ocurre cuando tratas la bandeja de entrada como una herramienta compartida en lugar de parte de la funcionalidad.
Los recorridos de cambio de correo electrónico son frágiles. Modifican cuentas activas. Tratas con usuarios autenticados y estados pendientes.
Los problemas comunes incluyen:
- Los mensajes llegan a una bandeja de entrada compartida sin un propietario claro.
- El enlace funciona, pero la UI muestra datos antiguos.
- El backend se actualiza, pero la caché del frontend permanece desactualizada.
- Los testers hacen clic en enlaces destinados a otros testers.
Para solucionar esto, utiliza un correo electrónico desechable (burner email) para cada ejecución de prueba. No utilices un único alias de staging.
Sigue esta secuencia:
- Crea un usuario de prueba a través de la aplicación.
- Solicita un cambio de correo electrónico en la configuración de React.
- Envía el correo a través del backend real.
- Dirige el mensaje a una bandeja de entrada de un solo uso.
- Abre el enlace y verifica que la pantalla de configuración muestre la nueva dirección.
El aislamiento mantiene clara la propiedad. No necesitarás notas desordenadas en Slack para recordar qué bandeja de entrada utilizaste.
Una regla para las aplicaciones React: comprueba siempre la pantalla después de una nueva lectura de datos. No confíes en el estado optimista del cliente (optimistic client state). La mutación puede devolver éxito, pero una recarga de la página podría recuperar el valor antiguo. Esto sucede más de lo que la gente admite.
Tu prueba end-to-end debe verificar:
- Que el correo se envíe a la nueva dirección pendiente.
- Que el enlace apunte al host correcto.
- Que el enlace actualice el registro de la cuenta.
- Que la dirección antigua desaparezca tras un refetch.
- Que el reuso del enlace falle de forma segura.
Las aserciones (assertions) del frontend son la parte más importante. Un log del backend que diga "success" es inútil si el usuario ve la dirección incorrecta. Si tu caché o tu store están desactualizados, la funcionalidad está rota.
La trazabilidad también ayuda. Utiliza un ID de correlación en tus logs y en los metadatos del correo electrónico. Esto conecta la solicitud con la entrega y la confirmación.
Compensaciones a considerar:
- El polling de la bandeja de entrada es más lento que los mocks.
- Las direcciones desechables solo deben contener datos que no sean de producción.
- Los entornos de vista previa (preview environments) necesitan reglas de limpieza.
No te saltes esto. Los flujos de correo electrónico se rompen en los huecos entre sistemas. Ahí es donde los mocks son más débiles.