Reparador de Tests Inestables

El Problema

Los tests flaky son el cancer de las pipelines CI. Pasan localmente pero fallan en CI, pasan en retry pero fallan aleatoriamente. Los desarrolladores dejan de confiar en la suite de tests. Las causas raiz — estado mutable compartido, dependencias de timing, aleatoriedad no controlada — son patrones consistentes que pueden diagnosticarse y arreglarse sistematicamente.

El Prompt

Diagnostica y repara el siguiente test flaky. Pasa la mayoria del tiempo pero falla intermitentemente, especialmente en CI.

TEST INESTABLE:
[pega el test que falla]

MENSAJE DE ERROR (cuando falla):
[pega la salida del error]

ENTORNO CI: [ej. GitHub Actions Ubuntu, Jenkins Docker]

Analizar estos patrones de flakiness:

1. **Problemas de Timing/Async** — awaits faltantes, race conditions, dependencias de setTimeout
2. **Estado Compartido** — tests dependen del orden, estado no reseteado entre tests
3. **Dependencias Externas** — llamadas de red, sistema de archivos, reloj del sistema
4. **Contencion de Recursos** — conflictos de puertos, locks de archivos, agotamiento del pool de conexiones
5. **Diferencias de Entorno** — CI tiene diferente timezone, locale, resolucion, limites de memoria

Para cada causa sospechada: explicar POR QUE, mostrar el FIX EXACTO, agregar asercion defensiva.

Ejemplo de Salida

// PROBLEMA: Test depende del orden de setTimeout
// ANTES:
it('muestra notificacion despues de guardar', () => {
  clickSave();
  expect(screen.getByText('Guardado!')).toBeVisible(); // INESTABLE
});

// FIX: Esperar el cambio de UI especifico
it('muestra notificacion despues de guardar', async () => {
  clickSave();
  await waitFor(() => {
    expect(screen.getByText('Guardado!')).toBeVisible();
  }, { timeout: 3000 });
});

Cuando Usar

Usar cuando un test falla intermitentemente en CI, cuando tu equipo tiene una lista de tests “conocidos como flaky” que se saltan, o cuando ves patrones de retry-hasta-que-pase en tu pipeline.

Tips Pro

• Ejecutar tests en orden aleatorio — usar flag --randomize para exponer tests dependientes del orden localmente.
• Cuarentena, luego arreglar — mover tests flaky a una suite separada, pero poner un deadline para arreglarlos.
• Agregar logs de timing — pedir a la IA que instrumente el test con timestamps en cada paso.
• Testear en Docker localmente — ejecutar tests en la misma imagen Docker que CI.