Los 8 anti-patrones que matan una suite

El catálogo

Ninguno de estos aparece de golpe. Se cuelan de a uno, con buenas intenciones y bajo presión de tiempo. Reconocerlos es la mitad de la cura.

1. El sleep fijo

await page.click('#guardar');
await page.waitForTimeout(3000);   // ❌ "por si acaso"

Es lo peor de dos mundos: si la app responde en 200 ms, regalas 2,8 segundos por test (× 400 tests = suite eterna); si un día tarda 3,5 s, el test falla igual. Cura: espera la condición concreta (que el mensaje aparezca, que la request termine).

2. El force: true

await page.click('#pagar', { force: true });   // ❌

Se usa cuando el clic "no funciona"… porque hay un banner tapando el botón. Con force el test pasa y el usuario real sigue sin poder pagar. Estás escondiendo un bug con la herramienta. Cura: si el usuario no puede hacer clic, tu test tampoco debería.

3. Asertar implementación en vez de comportamiento

// ❌ El cómo está hecho
expect(await div.getAttribute('class')).toContain('error-red');

// ✅ Lo que el usuario vive
await expect(page.getByRole('alert')).toHaveText('El teléfono no es válido');

El primero falla si renombran la clase (aunque todo funcione) y pasa si borran el mensaje pero dejan la clase (aunque esté roto). Lo peor de ambos mundos.

4. El test gigante

Un test de 120 líneas que hace login, busca, agrega al carrito, paga y verifica el mail. Cuando falla en la línea 90, no sabes qué se rompió, y nunca llegas a probar el mail porque muere antes. Cura: un test, una intención. Lo demás se siembra por API.

5. Selectores frágiles

By.xpath('/html/body/div[2]/div[3]/button')   // ❌ muere en el próximo refactor
'.btn-primary-lg-2'                            // ❌ es una clase de estilo

Se rompen con cambios visuales que no alteran ningún comportamiento. Cura: la jerarquía — rol accesible > label > data-testid > CSS semántico.

6. El skip eterno

test.skip('el checkout aplica el descuento', ...);   // "lo arreglo después"

Ese "después" nunca llega. Un test saltado por meses es cobertura falsa: el reporte dice verde y ese flujo no se prueba hace medio año. Cura: un skip tiene fecha de vencimiento y responsable, o se borra. Borrarlo es más honesto que fingir.

7. El reintento como analgésico

retries: 5   // ❌ "así ya no falla"

Subir los reintentos hasta que pase no arregla nada: esconde un test enfermo. Dos reintentos amortiguan ruido real de red; cinco son una confesión. Cura: cuarentena y diagnóstico.

8. Normalizar el rojo — el peor de todos

Todos los anti-patrones anteriores desembocan aquí. Por eso este es el termómetro: si tu equipo ignora el rojo, tienes un problema de suite, no de tests sueltos.

Cómo salir del pozo

Si heredaste una suite con todo esto, no intentes arreglarla entera: vas a fracasar y a desmoralizar al equipo.

1. Mide primero: ¿cuántos tests fallan seguido? ¿cuánto tarda? ¿cuántos skip hay?
2. Ataca el rojo normalizado. Cuarentena todo lo inestable hoy, para que la suite principal vuelva a ser confiable. Un verde honesto con 60 tests vale más que un rojo ambiguo con 400.
3. Un anti-patrón por sprint. Primero lo que quita confianza (flaky), después lo que quita velocidad (sleeps), al final lo estético.
4. Prohíbe la reincidencia en la revisión de código: sin sleeps, sin force, sin skip sin fecha.

Auditar y priorizar es un trabajo de criterio — exactamente lo que te hace senior.

Comprueba el catálogo en el quiz y audita tu suite en el reto.