¿Qué son las pruebas flaky y cómo se tratan?

Question

Accepted Answer

**Las pruebas flaky** son pruebas que **pasan o fallan de forma inconsistente** sin cambios en el código — a veces pasando, a veces fallando en el mismo código. Son un problema serio porque erosionan la confianza en el conjunto de pruebas. Comprender sus causas y soluciones es importante.

## Por qué es importante

```text
A FLAKY test gives INCONSISTENT results (pass sometimes, fail other times) on the SAME code:
  → harmful: ERODES TRUST — people start ignoring failures ("oh, it's just flaky") →
    real failures get missed too
  → waste time on false alarms / re-runs; break CI; reduce confidence in the whole suite
→ Flaky tests are worse than no test if they make people distrust all tests.
```

## Causas comunes

```text
✗ TIMING / async → race conditions; not waiting properly for async operations (a top cause
  in UI/E2E tests); arbitrary sleeps
✗ ORDER DEPENDENCE → tests depending on each other / shared mutable state
✗ EXTERNAL dependencies → real network/services (network blips, rate limits, downtime)
✗ NON-DETERMINISM → time/dates, randomness, timezone, locale
✗ Test ENVIRONMENT → leftover state, uncleaned data, concurrency/parallelism issues
```

## Corrección y gestión de pruebas flaky

```text
✓ Fix the ROOT CAUSE: wait for conditions (not sleeps); make tests INDEPENDENT and clean
  up state; MOCK external dependencies; control time/randomness (inject them)
✓ Ensure proper isolation (no shared state, no order dependence)
✓ Don't just RETRY blindly (it hides the problem) — investigate and fix
✓ QUARANTINE persistently flaky tests (isolate so they don't block) WHILE fixing them
✓ Treat flakiness seriously — track and address it (it degrades the whole suite)
```

## Por qué es importante

Comprender las pruebas flaky y cómo tratarlas es importante porque **las pruebas flaky son un problema serio y común que socava el valor de un conjunto de pruebas completo**, por lo que es un conocimiento práctico valioso.

Una prueba flaky (que pasa o falla de forma inconsistente en el mismo código) es particularmente dañina porque **erosiona la confianza**: cuando las pruebas fallan de forma impredecible, las personas comienzan a ignorar los fallos ("es solo flaky"), lo que significa que **los fallos reales también se pierden** — por lo que la inestabilidad degrada la confianza en el conjunto completo, potencialmente haciéndolo peor que inútil.

Comprender este daño motiva tomar la inestabilidad en serio.

Comprender las **causas comunes** — **problemas de tiempo/async** (condiciones de carrera, no esperar correctamente las operaciones async, esperas arbitrarias — una causa principal especialmente en pruebas de UI/E2E), **dependencia de orden** (pruebas que dependen unas de otras o de estado compartido), **dependencias externas** (servicios/red reales con sus problemas e interrupciones), **no-determinismo** (tiempo, aleatoriedad, zona horaria, configuración regional), y **problemas de entorno** (estado residual, concurrencia) — es necesario para diagnosticar la inestabilidad.

Comprender cómo **corregir y gestionar** — corregir las causas raíz (esperar condiciones en lugar de esperas, hacer que las pruebas sean independientes y limpias, simular dependencias externas, controlar el tiempo y la aleatoriedad), garantizar el aislamiento, **no reintentar ciegamente** (lo que oculta problemas), poner en cuarentena las pruebas persistentemente flaky mientras se corrigen, y tratar la inestabilidad como un problema serio para rastrear y abordar — refleja el enfoque correcto.

Ya que las pruebas flaky son un problema común y serio que socava la confianza en y el valor de un conjunto de pruebas (un problema real en muchos proyectos del mundo real), y ya que comprender sus causas y el manejo apropiado (corregir las causas raíz, aislamiento, no solo reintentar) es necesario para mantener un conjunto de pruebas confiable, comprender las pruebas flaky es un conocimiento valioso y prácticamente importante — abordando un problema de pruebas significativo en el mundo real, importante para mantener un conjunto de pruebas confiable y digno de confianza, y reflejando la madurez práctica para manejar uno de los problemas más frustrantes y dañinos de las pruebas.