Muchas pruebas End-to-End comienzan con una condición previa: un usuario existe, tiene un rol, cuenta con permisos, posee datos asociados o se encuentra en un estado específico. Si esa condición inicial no está controlada, la prueba puede fallar por motivos ajenos al flujo que queremos validar.
Preparar usuarios, permisos y estados iniciales es una parte fundamental del diseño E2E. No basta con ejecutar pasos; necesitamos saber desde qué situación parte el sistema.
En este tema veremos cómo organizar estos elementos para que las pruebas sean repetibles, claras y fáciles de diagnosticar.
El estado inicial es la situación del sistema antes de comenzar el escenario. Incluye los datos existentes, los permisos del usuario, las configuraciones activas y cualquier condición necesaria para que el flujo pueda ejecutarse.
Por ejemplo, para probar una reserva de turno, el estado inicial puede incluir: paciente registrado, profesional disponible, agenda abierta, turno libre y servicio de notificación configurado.
Un usuario de prueba es una cuenta creada para ejecutar escenarios sin afectar usuarios reales. Debe tener credenciales, datos y estado adecuados para la prueba.
Ejemplos habituales:
Estos usuarios deben estar documentados o crearse automáticamente, según la estrategia de datos del proyecto.
Los roles y permisos definen qué acciones puede realizar cada usuario. En pruebas E2E son importantes porque muchos flujos dependen de autorizaciones.
| Rol | Permiso esperado | Ejemplo de escenario E2E |
|---|---|---|
| Alumno | Comprar y ver cursos propios. | Compra un curso y lo ve en "Mis cursos". |
| Docente | Publicar y editar clases propias. | Publica una clase y la visualiza en el curso. |
| Administrador | Gestionar usuarios o aprobar contenidos. | Aprueba una solicitud pendiente. |
| Visitante | Solo acceder a páginas públicas. | Intenta entrar a una página privada y es redirigido al login. |
No alcanza con saber el rol del usuario. También importa su estado. Un mismo rol puede comportarse distinto según la situación de la cuenta.
Estados posibles:
Cuando el flujo depende de alguno de estos estados, la prueba debe prepararlo explícitamente.
Además de usuarios, muchas pruebas dependen del estado de entidades del negocio: productos, cursos, turnos, solicitudes, órdenes, documentos o pagos.
| Entidad | Estado inicial posible | Uso en E2E |
|---|---|---|
| Curso | Publicado, borrador, agotado, oculto. | Validar compra o acceso al contenido. |
| Turno | Disponible, reservado, cancelado. | Validar reserva o cancelación. |
| Solicitud | Borrador, pendiente, aprobada, rechazada. | Validar flujo de aprobación. |
| Orden | Creada, pagada, anulada, enviada. | Validar seguimiento de compra. |
Una prueba debe declarar qué estado necesita y qué cambio espera producir.
Existen varias formas de preparar el estado inicial de una prueba E2E:
La preparación debe ser lo más directa posible. Si el objetivo es probar la compra, no conviene gastar demasiado tiempo creando manualmente un curso desde la interfaz, salvo que esa creación también sea parte del riesgo que se quiere validar.
Una mala práctica es hacer que una prueba dependa del resultado de otra. Por ejemplo: una prueba crea un usuario, otra compra un curso con ese usuario y una tercera verifica el acceso al contenido.
Ese enfoque parece cómodo, pero genera problemas:
En algunos casos se reutilizan usuarios de prueba. En otros, conviene crear usuarios únicos por ejecución. Ambas estrategias pueden ser válidas si se aplican con criterio.
| Estrategia | Cuándo conviene | Riesgo |
|---|---|---|
| Usuario compartido | Para roles estables que no cambian durante la prueba. | Puede acumular estado o generar interferencias. |
| Usuario único | Para flujos que modifican datos personales, compras, reservas o estados. | Requiere creación y limpieza. |
Si una prueba modifica el estado del usuario, suele ser más seguro usar un usuario único o restaurar el estado antes de cada ejecución.
Los permisos son buenos candidatos para pruebas E2E cuando el riesgo está en el acceso completo al flujo. No se trata solo de verificar que un botón no aparezca, sino que el sistema impida acciones no autorizadas.
Ejemplos de verificaciones:
En permisos, es importante verificar tanto la interfaz como el resultado final. Ocultar un botón no alcanza si la acción todavía puede ejecutarse por otra vía.
También conviene pensar en estados iniciales inválidos o bloqueantes. Estos escenarios ayudan a validar que el sistema responda correctamente cuando el usuario no debería avanzar.
Ejemplos:
No todos estos casos deben ser E2E, pero los de mayor impacto pueden formar parte de la suite.
Para una plataforma de cursos, podríamos preparar distintos usuarios y estados:
| Escenario | Usuario necesario | Estado inicial | Resultado esperado |
|---|---|---|---|
| Comprar curso | Alumno activo. | Curso publicado y no comprado. | El curso aparece en "Mis cursos". |
| Acceder a curso no comprado | Alumno activo. | Curso publicado, pero no asociado al alumno. | El sistema bloquea el acceso al contenido. |
| Publicar clase | Docente autorizado. | Curso asignado al docente. | La clase queda visible en el curso. |
| Aprobar contenido | Administrador. | Clase pendiente de revisión. | La clase cambia a estado aprobada. |
Para mantener una suite E2E clara, conviene documentar qué usuarios y estados necesita cada escenario. Esta documentación evita suposiciones y facilita el mantenimiento.
Una ficha simple puede incluir:
Si el escenario falla, esta información ayuda a comprobar rápidamente si el ambiente estaba preparado como correspondía.
Al preparar usuarios, permisos y estados iniciales, son comunes estos errores:
Antes de ejecutar un escenario E2E, podemos revisar:
Usuarios, permisos y estados iniciales determinan desde dónde parte una prueba End-to-End. Si esos elementos no están definidos, la prueba puede volverse inestable o difícil de interpretar.
Una buena preparación permite que el escenario valide el flujo que realmente interesa, sin fallar por cuentas mal configuradas, permisos incorrectos o datos en estados inesperados.
En el próximo tema veremos la interacción con interfaces de usuario: formularios, navegación y validaciones.