Los datos de prueba son una parte central de las pruebas End-to-End. Un escenario E2E casi siempre necesita datos previos: usuarios, productos, permisos, turnos disponibles, solicitudes, estados, medios de pago o configuraciones.
Si los datos no están bien preparados, la prueba puede fallar aunque la aplicación funcione correctamente. También puede pasar lo contrario: la prueba puede pasar por casualidad porque encontró datos que quedaron de una ejecución anterior.
En este tema veremos cómo crear, aislar, limpiar y reutilizar datos para que las pruebas E2E sean más confiables.
Los datos de prueba son los datos que usamos para preparar, ejecutar y verificar un escenario. Pueden existir antes de comenzar la prueba, generarse durante la ejecución o comprobarse al final.
| Tipo de dato | Ejemplo | Uso en la prueba |
|---|---|---|
| Dato inicial | Usuario registrado. | Permite iniciar sesión antes de ejecutar el flujo. |
| Dato de entrada | Dirección de envío. | Se ingresa durante el escenario. |
| Dato generado | Número de orden. | Se crea como resultado del flujo. |
| Dato esperado | Curso visible en "Mis cursos". | Sirve para verificar que el resultado fue correcto. |
En pruebas End-to-End, los datos suelen atravesar muchas partes del sistema. Un usuario puede tener permisos, historial, estados previos, operaciones asociadas y restricciones. Un producto puede tener stock, precio, categoría, disponibilidad y reglas de compra.
Esto genera desafíos:
Por eso, la gestión de datos debe diseñarse junto con la prueba, no improvisarse al final.
Los datos fijos son datos que ya existen en el ambiente y que muchas pruebas pueden usar. Por ejemplo, un usuario administrador, una categoría de productos o una configuración básica.
Ventajas:
Riesgos:
Los datos fijos son útiles, pero deben estar controlados y documentados.
Otra estrategia es que cada prueba cree los datos que necesita. Esto mejora el aislamiento porque el escenario no depende tanto de datos existentes.
Por ejemplo, antes de probar una compra, la prueba puede crear un producto de prueba, un usuario y un medio de pago simulado. Luego ejecuta el flujo con esos datos.
Crear datos por prueba puede aumentar el tiempo de ejecución, pero suele mejorar la repetibilidad y reducir fallas por estado desconocido.
Los datos de prueba pueden crearse de varias maneras. La elección depende del sistema, del nivel de control y del costo aceptable.
| Forma | Ventaja | Limitación |
|---|---|---|
| Desde la interfaz | Muy realista. | Puede ser lenta y agregar pasos no relacionados con el objetivo. |
| Por API | Rápida y controlable. | Requiere endpoints disponibles y permisos adecuados. |
| Con scripts o herramientas internas | Permite preparar datos complejos. | Requiere mantenimiento técnico. |
| Mediante datos semilla | Deja el ambiente listo desde el inicio. | Puede volverse rígida si los escenarios cambian mucho. |
| Directamente en base de datos | Puede ser rápida. | Riesgosa si evita reglas del sistema o rompe consistencia. |
Aislar datos significa evitar que una prueba dependa de datos modificados por otra prueba o por otra persona. El aislamiento es clave para ejecutar pruebas de forma repetible.
Prácticas comunes:
Si una prueba necesita que otra se ejecute antes, la suite se vuelve más frágil. Cada escenario debería preparar lo necesario para sí mismo.
Muchas fallas aparecen porque dos ejecuciones intentan usar el mismo dato. Por ejemplo, registrar dos veces el mismo correo electrónico o reservar dos veces el mismo turno.
Para evitarlo, se pueden crear datos únicos por ejecución:
alumno+prueba123@ejemplo.com.La unicidad reduce conflictos y permite ejecutar pruebas repetidas o paralelas con menos interferencia.
Después de una prueba, pueden quedar datos creados: usuarios, órdenes, reservas, archivos, notificaciones o registros temporales. Si no se limpian, el ambiente se llena de información que puede afectar futuras ejecuciones.
La limpieza puede hacerse de distintas formas:
La limpieza debe ser segura. No debe borrar datos que no pertenecen a la prueba.
Una decisión común es limpiar antes de la prueba, después de la prueba o en ambos momentos.
| Momento | Ventaja | Riesgo |
|---|---|---|
| Antes | Asegura un estado inicial conocido. | Puede ocultar problemas si no se revisa qué dejó una prueba anterior. |
| Después | Deja el ambiente preparado para futuras ejecuciones. | Si la prueba falla antes de limpiar, pueden quedar datos residuales. |
| Antes y después | Mayor control. | Requiere más cuidado para no borrar datos incorrectos. |
En la práctica, conviene diseñar pruebas que no dependan de que la limpieza anterior haya sido perfecta.
Reutilizar datos puede ser conveniente cuando se trata de información estable y común, como roles, categorías, países, monedas o configuraciones básicas.
La reutilización es razonable cuando:
No conviene reutilizar datos que cambian como parte del flujo, por ejemplo una orden, una reserva disponible o un cupón de un solo uso.
En ambientes de prueba no deberían usarse datos personales reales, tarjetas reales, documentos reales, contraseñas reales ni información confidencial de usuarios.
Buenas prácticas:
Para una prueba E2E de compra de curso, podríamos definir estos datos:
| Dato | Estrategia | Motivo |
|---|---|---|
| Alumno | Crear o reutilizar usuario de prueba aislado. | Debe poder iniciar sesión y comprar. |
| Curso | Crear curso publicado para la ejecución. | Evita depender de cursos modificados por otras pruebas. |
| Medio de pago | Usar tarjeta de prueba aprobada. | Valida el flujo sin realizar pagos reales. |
| Orden generada | Capturar identificador y verificar resultado. | Permite diagnosticar y limpiar datos. |
Al trabajar con datos de prueba en E2E, conviene evitar estos errores:
Antes de ejecutar un escenario E2E, conviene revisar:
Gestionar datos de prueba es una de las tareas más importantes en pruebas End-to-End. Sin datos controlados, los escenarios pueden volverse impredecibles y perder valor.
La clave es preparar datos suficientes para validar el flujo, aislarlos para evitar interferencias, limpiarlos cuando corresponda y reutilizar solo aquellos que sean realmente estables.
En el próximo tema veremos usuarios, permisos y estados iniciales del sistema, un tema muy relacionado con la preparación de datos.