En este último tema integraremos los conceptos del curso en un caso práctico. Diseñaremos una prueba End-to-End para validar un flujo completo de compra de un curso en línea.
El objetivo no será escribir código dependiente de una herramienta específica, sino construir el razonamiento completo: qué validar, qué datos preparar, qué pasos ejecutar, qué verificar, qué evidencias guardar y cómo analizar fallas posibles.
Este tipo de caso ayuda a transformar los conceptos teóricos en una prueba E2E concreta, clara y mantenible.
Supongamos una plataforma de cursos en línea. Un alumno puede iniciar sesión, buscar un curso publicado, ver su detalle, comprarlo, pagar con un medio de prueba y luego acceder al contenido desde la sección "Mis cursos".
El flujo involucra varias partes:
El objetivo principal debe expresarse desde el punto de vista del usuario y del negocio.
Este objetivo deja claro qué se quiere validar: no solo que el pago muestre éxito, sino que la compra produzca la consecuencia importante para el alumno.
Este flujo es un buen candidato para una prueba End-to-End porque atraviesa varias capas y representa un proceso crítico del negocio.
| Criterio | Aplicación al caso |
|---|---|
| Valor para el usuario | El alumno quiere comprar y acceder al curso. |
| Valor para el negocio | La venta de cursos es una operación central. |
| Integración de capas | Participan UI, backend, base de datos, pago y permisos. |
| Riesgo si falla | El usuario puede pagar sin recibir acceso o no poder completar la compra. |
| Resultado observable | El curso aparece disponible en "Mis cursos". |
Definir el alcance evita que la prueba intente cubrir demasiado. En este caso, el escenario principal validará el camino feliz de compra con pago aprobado.
Incluiremos:
No incluiremos en este mismo escenario todas las variantes de cupones, pagos rechazados, recuperación de contraseña o cancelaciones. Esas variantes pueden tener pruebas separadas.
Antes de ejecutar la prueba, deben cumplirse ciertas condiciones. Si no se definen, la prueba puede fallar por preparación incorrecta.
| Condición | Detalle |
|---|---|
| Alumno | Existe un alumno registrado, activo y con correo verificado. |
| Curso | Existe un curso publicado, disponible para compra y no comprado por ese alumno. |
| Pago | El medio de pago de prueba permite simular una aprobación. |
| Ambiente | Frontend, backend, base de datos y servicios necesarios están disponibles. |
| Datos | La prueba puede identificar de forma única la orden que creará. |
Los datos deben ser controlados para evitar interferencias. Podemos usar datos creados por la prueba o datos preexistentes preparados especialmente para testing.
Datos necesarios:
Si la prueba crea el alumno y el curso antes de ejecutar, será más aislada. Si usa datos fijos, esos datos deben estar protegidos contra modificaciones accidentales.
El ambiente debe estar preparado para ejecutar el flujo sin afectar usuarios reales ni generar cargos reales.
Requisitos del ambiente:
Si el ambiente no es confiable, la prueba puede fallar por razones ajenas al flujo de compra.
Los pasos deben describir el recorrido del usuario sin mezclar todavía todos los detalles técnicos de implementación.
Estos pasos forman el flujo completo desde la intención de compra hasta el acceso al resultado.
Las verificaciones intermedias ayudan a detectar dónde se rompe el flujo si algo falla. No deben ser excesivas, pero sí útiles.
Podemos verificar:
Estas comprobaciones no reemplazan la verificación final, pero hacen más claro el diagnóstico.
La verificación final debe confirmar el objetivo principal del escenario. En este caso, el alumno debe poder acceder al curso comprado.
Esta verificación es más fuerte que revisar solo un mensaje de éxito. Comprueba una consecuencia real de negocio: la compra habilitó el acceso correspondiente.
Según el riesgo y el costo, podemos agregar verificaciones complementarias. No todas tienen que estar en el escenario crítico, pero conviene considerarlas.
| Verificación | Valor |
|---|---|
| La orden queda con estado pagada. | Confirma estado de negocio interno. |
| El importe de la orden coincide con el curso. | Detecta errores de cálculo o carrito. |
| El correo de confirmación llega a la bandeja de prueba. | Valida comunicación posterior a la compra. |
| El curso no aparece duplicado en "Mis cursos". | Detecta efectos repetidos o duplicación de acceso. |
Si estas verificaciones hacen demasiado largo el escenario principal, pueden separarse en pruebas específicas.
Para automatizar el flujo, necesitaremos ubicar elementos de forma estable. Conviene acordar identificadores claros con desarrollo.
| Elemento | Identificador posible |
|---|---|
| Campo correo de login | login-email-input |
| Campo contraseña | login-password-input |
| Botón iniciar sesión | login-submit-button |
| Botón comprar curso | course-buy-button |
| Botón confirmar pago | checkout-confirm-payment |
| Mensaje de compra confirmada | purchase-success-message |
| Curso en "Mis cursos" | my-courses-course-item |
Este flujo tiene varios puntos donde la prueba debe esperar correctamente. No conviene usar esperas fijas.
Esperas recomendadas:
Cada espera debe basarse en una condición observable del flujo.
El pago debe realizarse sin cargos reales. Podemos usar un proveedor sandbox o simular una respuesta aprobada, según el objetivo de la prueba.
| Opción | Cuándo usarla |
|---|---|
| Pago sandbox real | Cuando queremos validar la integración con el proveedor de prueba. |
| Respuesta simulada aprobada | Cuando queremos validar el flujo de negocio sin depender del proveedor. |
| Webhook simulado | Cuando el estado de pago llega de forma asincrónica. |
En cualquier caso, el escenario debe verificar que el resultado de pago se refleje correctamente en la orden y en el acceso al curso.
Si el escenario falla, necesitamos evidencia para diagnosticar. En un flujo de compra, algunos datos son especialmente útiles.
Evidencias recomendadas:
Estas evidencias ayudan a diferenciar defectos reales, problemas de ambiente, datos incorrectos o fallas del proveedor de pago.
El caso feliz de compra no cubre todos los riesgos. Podemos diseñar variantes separadas para escenarios importantes.
| Variante | Qué valida |
|---|---|
| Pago rechazado | El curso no se habilita y se informa el problema. |
| Alumno sin correo verificado | El sistema bloquea la compra o solicita verificación. |
| Curso no publicado | El curso no puede comprarse. |
| Cupón válido | El descuento se aplica correctamente al total. |
| Compra repetida | El sistema evita duplicar acceso o muestra que ya fue comprado. |
No todas estas variantes deben estar en la suite crítica. La selección depende del riesgo y del costo.
Una falla en este escenario puede tener varias causas. Clasificarlas ayuda a decidir la acción correcta.
| Falla observada | Causa posible | Qué revisar |
|---|---|---|
| No se puede iniciar sesión. | Credenciales, usuario inactivo o problema de autenticación. | Datos del alumno, logs de login y estado del usuario. |
| El curso no aparece disponible para comprar. | Curso no publicado, ya comprado o dato incorrecto. | Estado del curso y relación con el alumno. |
| El pago no se aprueba. | Sandbox caído, configuración incorrecta o respuesta simulada mal preparada. | Proveedor de pago, credenciales y logs de operación. |
| La orden se paga, pero el curso no se habilita. | Defecto real en regla de negocio o proceso asincrónico incompleto. | Estado de orden, eventos y permisos de acceso. |
| La prueba no encuentra el curso en "Mis cursos". | Sincronización, selector incorrecto o acceso no creado. | Captura, traza, selector y estado de datos. |
Podemos documentar el caso en una forma compacta para que el equipo lo entienda fácilmente.
| Nombre | Alumno compra un curso publicado y accede al contenido. |
|---|---|
| Objetivo | Validar que una compra aprobada habilita el curso comprado para el alumno. |
| Condición inicial | Alumno activo, curso publicado, pago de prueba disponible y ambiente estable. |
| Pasos principales | Iniciar sesión, abrir curso, comprar, pagar, confirmar y revisar "Mis cursos". |
| Resultado esperado | La orden queda aprobada y el curso aparece disponible para el alumno. |
| Evidencia | Número de orden, estado de pago, captura o traza si falla. |
Antes de incorporar este escenario a una suite E2E, podemos revisar:
En este curso recorrimos los conceptos principales de las pruebas End-to-End: qué son, cuándo usarlas, cómo seleccionar escenarios, preparar ambientes y datos, interactuar con la interfaz, manejar sincronización, definir verificaciones, tratar dependencias externas, analizar fallas y mantener una suite confiable.
El caso práctico de compra muestra cómo unir esas piezas en un escenario completo. Una buena prueba E2E no se limita a automatizar clics: valida un flujo importante, con condiciones claras, datos controlados, verificaciones fuertes y evidencia útil.
La idea central del curso es usar pruebas End-to-End con criterio: pocas, valiosas, claras y mantenibles, enfocadas en los flujos que realmente importan para el usuario y para el negocio.