Módulo 5 · Automatización

4 horas — 1 h 30 de teoría, 2 h 30 de práctica.

Automatizar no es "grabar clics". Es escribir código que comprueba, de forma repetible, que el sistema hace lo que debe. Este módulo lo hacemos con Playwright, que sirve tanto para web como para API.

Objetivos

Decidir qué vale la pena automatizar y qué no.
Escribir pruebas web con selectores estables.
Escribir pruebas de API con aserciones útiles.
Ejecutar las pruebas en el pipeline y leer el reporte.

Entregable

Un escenario web y un escenario de API automatizados, subidos a tu repositorio y ejecutándose en verde en el pipeline (o en rojo por un defecto real, con la explicación).

Parte teórica

Objetivos y beneficios (20 min)

Automatizar sirve para lo que a una persona le resulta tedioso y a una máquina trivial: repetir la misma comprobación muchas veces, siempre igual.

Lo que la automatización sí da: regresión rápida, ejecución en cada cambio, resultados reproducibles, documentación viva de lo que el sistema debe hacer.

Lo que no da: no encuentra defectos nuevos por su cuenta, no reemplaza las pruebas exploratorias, y una prueba mal escrita da falsa confianza (peor que no tener prueba).

Qué automatizar y qué no (20 min)

Buen candidato	Mal candidato
Se repite en cada versión	Se ejecuta una vez y nunca más
El resultado es determinista	Depende de criterio humano (¿se ve bien?)
Cubre un camino crítico	Cubre un caso rarísimo
Es estable	El área está en rediseño constante
Falla de forma clara	Falla de forma intermitente

Regla práctica: automatiza primero el camino feliz de lo crítico, después los casos negativos que más duelen.

Automatización web: selectores (25 min)

El 90% de las pruebas web frágiles lo son por el selector. Orden de preferencia:

Prioridad	Selector	Por qué
1	`data-testid`	Existe solo para pruebas. Nadie lo cambia por estética.
2	Rol accesible (`getByRole`)	Estable y además valida accesibilidad
3	Texto visible	Se rompe al traducir o reescribir
4	Clase CSS	Cambia con cualquier retoque de diseño
5	XPath posicional	Se rompe si se añade un `<div>`

ReservaLab tiene data-testid en todos los elementos interactivos. Úsalos siempre: el inventario completo está aquí.

// Bien: sobrevive a rediseños
await page.getByTestId('boton-confirmar').click();

// Mal: se rompe cuando cambien el texto del botón
await page.getByText('Confirmar').click();

Automatización de APIs (15 min)

Las pruebas de API son más rápidas y estables que las de interfaz, porque no dependen del navegador. Regla: si puedes comprobarlo por API, hazlo por API; reserva las pruebas de interfaz para lo que solo se ve en la interfaz.

Una aserción útil comprueba tres cosas: código de estado, forma de la respuesta y contenido relevante.

const res = await request.get(`${API}/services`);
expect(res.status()).toBe(200);              // estado
const cuerpo = await res.json();
expect(cuerpo).toHaveProperty('servicios');  // forma
expect(cuerpo.total).toBeGreaterThan(0);     // contenido

Estructura del proyecto (10 min)

Tu repositorio ya viene con todo montado:

studentNN-qa/
├── tests/
│   ├── api.spec.ts        Pruebas de API
│   └── web.spec.ts        Pruebas de interfaz
├── playwright.config.ts   Configuración (URLs, reintentos, reportes)
├── package.json           Dependencias y comandos
└── .gitea/workflows/qa.yml  El pipeline

La versión de Playwright está fijada a propósito

En package.json verás "@playwright/test": "1.62.0", sin ^. Los navegadores viven dentro de la imagen del pipeline, que trae exactamente esa versión. Si actualizas la dependencia sin actualizar la imagen, todas las pruebas web fallan con "Executable doesn't exist". Es un error clásico de CI.

Parte práctica

Ejercicio 1 · Configurar el proyecto (25 min)

bash

git clone https://gitea.theproject.ec/studentNN/studentNN-qa.git
cd studentNN-qa

npm install
npx playwright install chromium

Configura tus credenciales (en Linux/macOS):

bash

export STUDENT_EMAIL=studentNN@theproject.ec
export STUDENT_PASSWORD=tu-contraseña

En Windows con PowerShell:

powershell

$env:STUDENT_EMAIL="studentNN@theproject.ec"
$env:STUDENT_PASSWORD="tu-contraseña"

Comprueba que arranca:

bash

npm test

Deberían pasar las 11 pruebas que vienen de ejemplo. Si fallan, revisa las variables de entorno antes de tocar el código.

Ejercicio 2 · Automatizar un flujo web (55 min)

Abre tests/web.spec.ts y estúdialo: ahí está el patrón que vas a seguir.

2.1 Ejecuta solo las pruebas web en modo interactivo. Es la mejor forma de entender qué hace cada línea:

bash

npm run test:ui

2.2 Escribe una prueba nueva: no se puede reservar una cita en el pasado desde la interfaz.

test('la interfaz no permite reservar en el pasado', async ({ page }) => {
	// 1. Inicia sesión (reutiliza el helper del archivo)
	// 2. Elige un servicio
	// 3. Pon una fecha de la semana pasada
	// 4. Confirma
	// 5. Comprueba que aparece un mensaje de ERROR y no de éxito
});

¿Y si aparece un mensaje de éxito?

Entonces has encontrado un defecto. Compruébalo por partida doble: consulta GET /appointments o la base de datos y verifica si la cita se creó de verdad. Si el mensaje dice "éxito" y la cita no existe, la interfaz está mintiendo. Repórtalo.

2.3 Escribe una prueba de doble clic en Confirmar:

test('un doble clic no crea la cita dos veces', async ({ page }) => {
	// Rellena el formulario y haz dos clics seguidos y rápidos en confirmar.
	// Comprueba que solo se creó UNA cita.
});

Usa dblclick() o dos click() seguidos sin esperar entre ellos.

Pista

Cuenta las filas antes y después. Si aparecen dos citas idénticas, tienes un defecto grave: hay que documentar qué debería pasar (el botón debería deshabilitarse, y el servidor debería rechazar la segunda) y qué pasa en realidad.

Ejercicio 3 · Automatizar una validación de API (35 min)

Abre tests/api.spec.ts.

3.1 Escribe una prueba: un cliente no puede cancelar la cita de otro.

test('no se puede cancelar una cita ajena', async ({ request }) => {
	// 1. Inicia sesión con tu usuario y obtén tu token
	// 2. Necesitas el id de una cita que NO sea tuya.
	//    Pídele a un compañero el id de una de sus citas.
	// 3. Intenta cancelarla con TU token
	// 4. Espera un 403
});

¿Devuelve 200?

Es el defecto de seguridad más grave del laboratorio. Se llama IDOR (referencia directa insegura a objetos): el sistema comprueba que estás autenticado, pero no que el recurso sea tuyo. Documenta la severidad como crítica y explica el impacto: cualquier cliente puede cancelar las citas de cualquier otro.

3.2 Escribe una prueba de validación de entrada: el registro rechaza un email con formato inválido.

test('el registro rechaza un email inválido', async ({ request }) => {
	// POST /auth/register con email "no-soy-un-email"
	// Espera 400
});

3.3 Escribe una prueba de manejo de errores: un cuerpo vacío devuelve 400, no 500.

Ejercicio 4 · Ejecutar en el pipeline (20 min)

bash

git checkout -b feat/mis-pruebas
git add tests/
git commit -m "test: pruebas de cancelacion ajena y validacion de email"
git push -u origin feat/mis-pruebas

Ve a Gitea → Actions y sigue la ejecución.

¿En qué etapa falla, si falla?
Descarga el artefacto reporte-playwright y ábrelo. Mira las capturas de pantalla de las pruebas fallidas.
Para cada prueba en rojo, responde: ¿está mal mi prueba o hay un defecto en la aplicación? Justifícalo.

Una prueba en rojo por un defecto real es un éxito

No "arregles" la prueba para que pase. Documenta el defecto y deja la prueba fallando: es lo que hace visible el problema en cada ejecución.

Ejercicio 5 · Refactorizar y documentar (15 min)

Revisa tus pruebas y aplica tres mejoras:

Extrae lo repetido a una función (el login, por ejemplo).
Nombra las pruebas describiendo el comportamiento, no la mecánica: 'no se puede cancelar una cita ajena', no 'test cancel 403'.
Deja el sistema como estaba. Si tu prueba crea una cita, cancélala al final (y espera a que la cancelación se refleje antes de terminar, o la petición se aborta al cerrar la página).

Sube el refactor en un commit aparte.

Cierre

[ ] El proyecto corre en tu máquina
[ ] Al menos 2 pruebas web nuevas
[ ] Al menos 2 pruebas de API nuevas
[ ] Todo subido y ejecutándose en el pipeline
[ ] Para cada prueba en rojo, la explicación de por qué

Módulo 5 · Automatización ​

Objetivos ​

Entregable ​

Parte teórica ​

Objetivos y beneficios (20 min) ​

Qué automatizar y qué no (20 min) ​

Automatización web: selectores (25 min) ​

Automatización de APIs (15 min) ​

Estructura del proyecto (10 min) ​

Parte práctica ​

Ejercicio 1 · Configurar el proyecto (25 min) ​

Ejercicio 2 · Automatizar un flujo web (55 min) ​

Ejercicio 3 · Automatizar una validación de API (35 min) ​

Ejercicio 4 · Ejecutar en el pipeline (20 min) ​

Ejercicio 5 · Refactorizar y documentar (15 min) ​

Cierre ​

Módulo 5 · Automatización

Objetivos

Entregable

Parte teórica

Objetivos y beneficios (20 min)

Qué automatizar y qué no (20 min)

Automatización web: selectores (25 min)

Automatización de APIs (15 min)

Estructura del proyecto (10 min)

Parte práctica

Ejercicio 1 · Configurar el proyecto (25 min)

Ejercicio 2 · Automatizar un flujo web (55 min)

Ejercicio 3 · Automatizar una validación de API (35 min)

Ejercicio 4 · Ejecutar en el pipeline (20 min)

Ejercicio 5 · Refactorizar y documentar (15 min)

Cierre