- ¿Su aplicación es fácil de entender y usar, incluso para personas con alguna discapacidad?
- ¿Su aplicación debe funcionar en distintos navegadores y dispositivos?
- ¿Su aplicación debe funcionar en entornos multinacionales y/o internacionales?
- ¿Cómo se comportará su aplicación cuando se someta a cargas de producción imprevistas?
- ¿Cómo puede asegurarse de que su aplicación esté protegida frente a vulnerabilidades de seguridad?
Pruebas unitarias
Pruebas de integración
- Para usar variables en Rules, consulte cómo configurar valores
- Para usar variables en Hooks, consulte cómo configurar secretos en el editor
- Para usar variables en Actions, consulte Explorar flujos y activadores
- Para usar variables en Custom DB Scripts, consulte los parámetros de configuración
Práctica recomendada
Se recomienda usar variables para almacenar valores específicos del inquilino, así como cualquier secreto sensible que no deba exponerse en su código personalizado. Si su código personalizado está desplegado en GitHub, usar una variable específica del inquilino evita exponer valores sensibles a través de su repositorio de GitHub.Automatización de pruebas
Pruebas con Mock
Pruebas de penetración (opcional)
Pruebas de carga (opcional)
- Ejecute un rastreo HTTP en una ejecución de prueba de su aplicación para identificar todas las llamadas que su aplicación o la prueba prevista deben realizar, y asegúrese de que la prueba las incluya para que sea representativa de lo que ocurrirá en producción.
- Diseñe su prueba teniendo en cuenta los límites de frecuencia de la API de Auth0.
- El uso de cualquier código personalizado en Auth0 (Actions, Rules, Hooks, scripts de base de datos personalizada, conexiones personalizadas de ) invocará el sandbox de código personalizado de Auth0, y esto puede suponer un mayor costo en términos de rendimiento. Desactive las Rules, salvo que sean esenciales para la prueba. Si están desactivadas, tendrá un mayor rendimiento que si están activadas.
- Estime la carga total esperada para su entorno de producción y el porcentaje de llamadas a cada endpoint, y estructure su prueba de rendimiento en consecuencia para obtener un resultado realista. Los distintos endpoints tienen costos de rendimiento diferentes. No diseñar una prueba representativa dará lugar a resultados engañosos.
- No realice llamadas que dependan de los resultados de llamadas anteriores sin comprobar que las llamadas o respuestas previas necesarias se hayan completado. Limitarse a introducir un retraso puede no ser suficiente.
- Asegúrese de implementar una gestión de errores adecuada. Una causa frecuente de problemas durante las pruebas son los errores en el código personalizado (Actions, Rules, Hooks, scripts de base de datos personalizada, scripts personalizados de conexión OAuth) provocados por excepciones no controladas en el código personalizado.
- Las pruebas de carga deben escribirse de modo que comiencen en un nivel bajo y aumenten la carga gradualmente, capturando datos en cada nivel, a fin de obtener los resultados más útiles. Comenzar en un nivel alto y fallar de inmediato aporta menos información sobre lo que el sistema puede soportar.
- Es normal tener que ejecutar una prueba de rendimiento varias veces, posiblemente ajustando el código sometido a prueba o la infraestructura/configuración de la prueba. Asegúrese de comenzar las pruebas con antelación para disponer de tiempo suficiente para más de una iteración.
- Use su propia cuenta de proveedor de correo y asegúrese de disponer con antelación de una cuota suficiente de envío de correo, o el proveedor de correo podría aplicarle límites de frecuencia. Desactive el envío de correo si no lo utiliza.
- Asegúrese de usar las credenciales de su propia cuenta para todas las conexiones sociales en lugar de las claves de desarrollo de Auth0. En el , vaya a Connections -> Social -> {name of connection}—para ver instrucciones sobre cómo añadir a la conexión las credenciales de su propia cuenta del proveedor social. Nota: algunos proveedores sociales no permiten pruebas de carga. Consulte la política de sus proveedores.
- Para evitar los límites de frecuencia y simular con mayor precisión una carga real, sus pruebas deberán enviar solicitudes de distintos usuarios, no todas las solicitudes para el mismo usuario. Si usa solo uno o unos pocos usuarios, el almacenamiento en caché puede reducir la carga efectiva y no proporcionar resultados realistas.
- Asegúrese de mantenerse dentro de los parámetros acordados para la prueba y de la política de pruebas de carga de Auth0. Auth0 se reserva el derecho de interrumpir cualquier prueba de rendimiento/carga que no se mantenga dentro de los límites de los parámetros acordados o que se extienda más allá del período programado para la prueba.