Muchas pruebas End-to-End interactúan con la aplicación a través de la interfaz de usuario. Esto significa que recorren pantallas, completan formularios, presionan botones, navegan entre secciones y verifican mensajes o resultados visibles.
Este tipo de interacción es valiosa porque se parece a la experiencia real del usuario. Pero también puede volver las pruebas más sensibles a cambios visuales, textos, tiempos de carga o navegación.
En este tema veremos cómo pensar las interacciones con formularios, navegación y validaciones para que las pruebas E2E sean claras y confiables.
En una prueba E2E basada en interfaz, la pantalla es la puerta de entrada al sistema. El escenario se ejecuta de una forma parecida a como lo haría una persona: abrir una página, escribir datos, seleccionar opciones y confirmar acciones.
Por ejemplo, completar un formulario de compra puede terminar creando una orden, descontando stock, registrando un pago y enviando una confirmación.
Los formularios aparecen en muchos flujos: registro, login, compra, reserva, solicitudes, búsqueda, contacto o configuración. Una prueba E2E debe interactuar con ellos de manera realista y verificar consecuencias.
Al probar formularios conviene observar:
En E2E no hace falta probar todas las combinaciones de campos. Deben elegirse las que aportan valor al flujo completo.
Un formulario suele tener campos obligatorios y opcionales. El escenario feliz normalmente completa los campos necesarios para avanzar correctamente. Los escenarios de error pueden validar qué ocurre cuando falta información importante.
| Campo | Tipo | Qué podría probarse |
|---|---|---|
| Correo electrónico | Obligatorio | El usuario no puede registrarse si está vacío o tiene formato inválido. |
| Dirección de envío | Obligatorio para entrega a domicilio | La compra no avanza si falta la dirección. |
| Cupón | Opcional | Si se ingresa un cupón válido, se aplica el descuento. |
| Comentario | Opcional | No debería bloquear el envío si queda vacío. |
Las validaciones visibles son mensajes o señales que la interfaz muestra al usuario cuando falta un dato, hay un formato incorrecto o una acción no está permitida.
En pruebas E2E, podemos verificar:
Un mensaje de error correcto no alcanza si, por detrás, la operación se creó igual. La prueba debe verificar el comportamiento completo.
Algunas validaciones ocurren en el frontend antes de enviar datos. Otras ocurren en el backend, donde se aplican reglas definitivas. En E2E, lo importante es que el usuario reciba una respuesta correcta y que el sistema quede consistente.
| Validación | Dónde puede ocurrir | Ejemplo |
|---|---|---|
| Formato de correo | Frontend y backend | Rechazar usuario-sin-arroba. |
| Stock disponible | Backend | Bloquear compra si el producto ya no tiene stock. |
| Campo obligatorio | Frontend y backend | No permitir enviar una solicitud sin descripción. |
| Permiso de usuario | Backend, con reflejo en frontend | Evitar que un usuario común apruebe una solicitud. |
Una prueba E2E no necesita saber todos los detalles internos, pero sí debe comprobar el resultado visible y las consecuencias principales.
Muchos flujos E2E dependen de navegar entre pantallas. Por ejemplo: listado, detalle, formulario, confirmación y vista final.
Al probar navegación conviene verificar:
La navegación no debe probarse como una lista de enlaces aislados, sino como parte de un objetivo del usuario.
En una pantalla puede haber muchas acciones: guardar, cancelar, volver, editar, eliminar, filtrar, ordenar, confirmar o descargar. Una prueba E2E debe enfocarse en las acciones que forman parte del flujo elegido.
Ejemplo en una compra:
Incluir acciones no relacionadas hace que la prueba sea más larga y más difícil de diagnosticar.
Los mensajes visibles son evidencias importantes, pero no siempre son suficientes. Una prueba E2E puede verificar un mensaje de éxito, pero también debería comprobar que el resultado realmente ocurrió.
| Mensaje | Verificación adicional recomendada |
|---|---|
| Compra realizada con éxito. | La orden aparece en el historial y el producto está asociado al usuario. |
| Turno reservado. | El turno aparece en la agenda y ya no figura disponible para otro usuario. |
| Solicitud enviada. | La solicitud queda registrada con estado pendiente. |
| Pago rechazado. | No se crea una compra aprobada ni se habilita el acceso al producto. |
Algunos procesos se dividen en varios pasos, como un asistente de compra, alta de solicitud o configuración inicial. En estos casos, la prueba debe verificar que el usuario pueda avanzar y que el estado se conserve.
Aspectos a revisar:
En flujos largos, conviene evitar verificaciones innecesarias en cada paso y concentrarse en los puntos donde puede romperse el proceso.
Interactuar con la interfaz puede revelar problemas que no aparecen en pruebas internas. Algunos ejemplos:
Estos problemas afectan directamente la experiencia y son buenos candidatos para pruebas E2E cuando ocurren en flujos críticos.
Una prueba E2E debe interactuar con la interfaz, pero no debería depender de detalles visuales innecesarios. Si la prueba falla cada vez que cambia un texto menor, una clase CSS o el orden de elementos secundarios, será costosa de mantener.
Conviene enfocar la prueba en:
En temas posteriores veremos selectores e identificadores confiables con más detalle.
Un escenario E2E de registro puede diseñarse así:
| Objetivo | Verificar que un usuario pueda registrarse y acceder a su cuenta. |
|---|---|
| Estado inicial | El correo de prueba no está registrado. |
| Interacción | Abrir registro, completar datos válidos, enviar formulario y confirmar acceso. |
| Validación principal | El usuario queda registrado y accede al panel inicial. |
| Escenario de error relacionado | Intentar registrar un correo ya existente y verificar que no se cree una cuenta duplicada. |
Al diseñar pruebas E2E con interfaz de usuario, conviene evitar estos errores:
Para revisar una prueba E2E basada en interfaz, podemos preguntar:
Las pruebas E2E que interactúan con interfaces de usuario permiten validar flujos desde una perspectiva cercana al uso real. Esto aporta mucha confianza, especialmente en procesos donde formularios, navegación y validaciones son parte esencial de la experiencia.
El desafío es mantener el foco: la prueba debe representar un objetivo del usuario y verificar consecuencias importantes, no acumular clics ni depender de detalles visuales frágiles.
En el próximo tema veremos sincronización, esperas y problemas de pruebas inestables, uno de los temas más importantes cuando se prueban interfaces modernas.