Datos de prueba y aislamiento

El culpable número uno de los fallos aleatorios

Tu suite pasa perfecto en tu máquina, en serie. La subes a CI con 4 workers y empieza a fallar al azar: a veces el test 12, a veces el 30, nunca el mismo. No es la herramienta ni la red: casi siempre son datos compartidos.

Dos tests que usan el mismo usuario, el mismo registro o reservan la misma hora funcionan bien mientras corran uno después de otro. En paralelo se pisan.

Factories: datos únicos por test

La cura es que cada test cree lo suyo. Una factory genera datos frescos y únicos:

import { randomUUID } from 'crypto';

export function makeCliente(overrides = {}) {
  const id = randomUUID().slice(0, 8);
  return {
    nombre: `Test ${id}`,
    email: `test-${id}@ejemplo.cl`,   // único: nunca choca
    telefono: '+56 9 1234 5678',
    ...overrides,                      // el test pide solo lo que le importa
  };
}

Dos cosas que la hacen buena:

• Unicidad por defecto (el uuid): dos tests nunca generan el mismo email.
• Overrides explícitos: el test declara solo el campo que le interesa (makeCliente({ nombre: 'Ana' })); el resto es ruido válido generado. Así el test comunica su intención.

Siembra por API, verifica por UI

Crear el usuario llenando el formulario de registro en cada test es lento y frágil: tu test de checkout falla porque cambió el registro, algo que ni siquiera estaba probando.

// ✅ El setup pesado, por API (rápido y estable)
const cliente = await api.crearCliente(makeCliente());

// ✅ La UI, solo para lo que el test verifica de verdad
await reservas.comoCliente(cliente).reservar('Corte', horaLibre);

Regla: prepara por API, verifica por UI. La UI se usa donde aporta valor de prueba, no como herramienta de setup.

Idempotencia y limpieza

Un test idempotente puede correrse 1 o 100 veces con el mismo resultado. Si el segundo intento falla con "el email ya existe", tu test no es idempotente y va a fallar en cada re-ejecución de CI.

Dos estrategias, ambas válidas:

• Crear único y limpiar (fixture con teardown). Lo más limpio.
• Crear único y no limpiar, en un entorno desechable que se recrea. Más simple si tienes esa infraestructura.

Lo que no funciona: reutilizar datos fijos y "esperar" que estén como los dejaste.

La regla de oro

Un test debe poder correr solo, en cualquier orden, cuantas veces quieras y al mismo tiempo que los demás.

Si cumple eso, paralelizas sin miedo y los reintentos funcionan. Si no lo cumple, ninguna herramienta ni reintento te va a salvar: solo van a esconder el problema hasta que explote en el peor momento.

Comprueba el criterio en el quiz y rediseña los datos en el reto.