Guía de pruebas de autenticación
Cómo probar flujos de OTP por correo
Una prueba de OTP por correo debe conservar el código exactamente como se entregó, enviarlo mediante el mismo endpoint o formulario que usaría una persona y verificar las reglas del proveedor sobre caducidad, intentos y reenvíos. InboxTap aporta el destinatario aislado y la espera acotada; la prueba de la aplicación demuestra el resultado de autenticación.Anota el contrato del OTP
Confirma la longitud y el alfabeto del código, su periodo de validez, el máximo de intentos, la estrategia de reenvío y si solicitar un segundo código invalida el primero. No presentes seis dígitos como una norma universal de OTP: Better Auth usa seis de forma predeterminada, pero permite configurarlos, y Supabase acepta longitudes de seis a diez dígitos.
Conserva el valor como cadena durante toda la prueba. Convertirlo a número elimina los ceros iniciales y puede impedir que se introduzca un código válido exactamente como lo recibió el usuario.
Captura el primer código
Crea un buzón para la prueba, inicia la acción de envío de código de la aplicación y llama a waitForCode() con un filtro de asunto. Su expresión predeterminada encuentra un valor de seis dígitos en el texto o el HTML capturados; proporciona una expresión regular o un patrón de cadena cuando la aplicación use otro formato.
Envía la cadena devuelta mediante el formulario o endpoint real de verificación y comprueba después la identidad autenticada y la sesión. Una prueba que solo encuentra dígitos en un correo no demuestra que el servidor acepte el código previsto.
Distingue un mensaje reenviado
Captura el primer mensaje completo y conserva su identificador. Después de solicitar otro código, waitForMessage() con afterId devuelve una entrega posterior; extrae el código nuevo de ese mensaje concreto como se muestra.
No uses waitForCode({ afterId }) para esta comprobación. El ayudante examina primero los mensajes existentes en busca de un valor coincidente, por lo que puede devolver el código anterior antes de que su solicitud de espera prolongada aplique afterId. Esperar el segundo mensaje hace explícito el límite de entrega.
const firstEmail = await inbox.waitForMessage({
subject: /code/i,
timeoutMs: 20_000,
});
await requestAnotherCode();
const secondEmail = await inbox.waitForMessage({
subject: /code/i,
afterId: firstEmail.id,
timeoutMs: 20_000,
});
const secondCode = secondEmail.text.match(/\b\d{6}\b/)?.[0];
expect(secondCode).toBeDefined();Prueba la rotación y los límites de intentos
Cuando la estrategia de reenvío configurada rote los códigos, demuestra que el primero falla y el segundo funciona. Si el proveedor reutiliza deliberadamente un código que aún no ha caducado, comprueba ese comportamiento. No conviertas en garantía del producto el valor predeterminado que estuviera instalado.
Envía valores no válidos hasta alcanzar el límite configurado y confirma que el intento siguiente se rechaza como se documenta. Usa las respuestas de la aplicación y el estado almacenado de la sesión; InboxTap no implementa ni observa el contador de verificación del proveedor.
Gestiona códigos más largos y personalizados
CapturedEmail.codes es una ayuda de análisis para secuencias únicas de entre cuatro y ocho dígitos. Un patrón personalizado de waitForCode() examina directamente el cuerpo del mensaje; úsalo para un código de Supabase de nueve o diez dígitos o para un formato alfanumérico propio de la aplicación.
Haz que la expresión regular sea lo bastante precisa para no confundir fechas, números de asistencia ni otros identificadores de la plantilla. Un asunto estable junto con un límite específico del formato es más seguro que elegir la primera secuencia de dígitos.
Prueba la caducidad con un reloj controlado
Prefiere un reloj virtual admitido por el proveedor, una fuente de tiempo inyectada o una caducidad breve exclusiva de las pruebas. Esperar durante toda la vigencia de producción ralentiza la batería y todavía deja condiciones de carrera cerca del límite.
El código caducado debe fallar sin crear ni ampliar una sesión. Solicitar uno nuevo después de la caducidad debe seguir la política de reenvío documentada y producir una entrega distinguible.
Evita mostrar secretos
No incluyas el OTP en nombres de pruebas, mensajes de comprobación, capturas de pantalla ni registros habituales. Comprueba su forma y el estado resultante de la aplicación en vez de tomar una instantánea del cuerpo completo del correo.
Si necesitas un artefacto de CI, usa el recopilador acotado de informes de InboxTap con patrones propios del proyecto para ocultar datos sensibles y revisa el resultado. La detección de tokens no garantiza que se encuentren todos los valores personales o secretos personalizados.
Adapta la receta al formato de tu OTP
Usa la referencia del SDK para elegir el patrón de espera adecuado, distinguir mensajes sucesivos, inspeccionar el contenido capturado y añadir diagnósticos seguros a los comparadores.
Explorar el SDK de cliente