La compilación se pone roja, alguien hace clic en “volver a ejecutar”, pasa y todos siguen adelante. Parece inofensivo, pero las pruebas deficientes destruyen lentamente lo más valioso que tiene un conjunto de pruebas: la confianza de la gente en él. Cuando las fallas suelen ser ruido, los errores reales también se detectan.

Esta guía explica por qué las pruebas se vuelven inestables y cómo solucionar cada causa adecuadamente. Ejecutamos las demostraciones de sincronización y estado compartido en Python 3.13, y los números que se muestran provienen de esas ejecuciones. Son pequeñas demostraciones diseñadas para hacer que la descamación sea fácil de ver, por lo que sus propias tasas de fracaso serán diferentes.

¿Qué es una prueba escamosa?

Una prueba inestable da resultados diferentes en el mismo código. Pasa en una ejecución y falla en la siguiente, aunque no haya cambiado nada en el producto. La prueba puede tener un error o el código puede contener un error intermitente real. Esa segunda posibilidad es exactamente la razón por la que no deberías simplemente descartarlas.

¿Por qué las pruebas inestables son tan costosas?

• Confianza perdida. Una vez que las personas asumen que el rojo significa “probablemente inestable”, dejan de investigar fallas reales.
• Tiempo perdido. Los desarrolladores pasan horas volviendo a ejecutar canalizaciones y examinando fallas que no tienen nada que ver con su cambio.
• Entrega más lenta. Fusiona y libera la espera en las reposiciones, lo que socava el objetivo de CI/CD.
• Errores ocultos. Las condiciones de carrera en el producto pueden parecerse al ruido de prueba, y esos son los que perjudican en la producción.

Causas comunes de un vistazo

Causa 1: sincronización y sueño fijo

Esta es la causa más común. Una prueba supone que el trabajo en segundo plano finalizará después de un retraso fijo. Para ver el efecto, escribimos una pequeña prueba en la que el trabajo tarda hasta 2 ms, mientras que la prueba espera solo 1 ms antes de verificar:

def flaky_timing():
    result = {}
    def work():
        time.sleep(random.uniform(0, 0.002))
        result["done"] = True
    threading.Thread(target=work).start()
    time.sleep(0.001)        # hope it has finished
    assert result.get("done")

La solución es esperar la condición real, con un límite superior generoso:

def fixed_timing():
    result = threading.Event()
    def work():
        time.sleep(random.uniform(0, 0.002))
        result.set()
    threading.Thread(target=work).start()
    assert result.wait(timeout=1)   # continues as soon as it is ready

Ejecutamos cada versión 200 veces:

El resultado es más que solo confiabilidad. La versión fija avanza en el momento en que se realiza el trabajo, por lo que suele ser también más rápida. Una suspensión más prolongada haría que la primera versión fallara con menos frecuencia, pero cada ejecución sería más lenta y aún podría fallar en una máquina de CI ocupada.

En las pruebas de navegadores se aplica el mismo principio. Utilice la espera automática de Dramaturgo, o Esperas de selenio explícitas, en lugar de time.sleep:

# Playwright: retries until true or a timeout is reached
expect(page.get_by_text("Order placed")).to_be_visible()

# Selenium: an explicit wait for a condition
WebDriverWait(driver, 10).until(
    EC.visibility_of_element_located((By.ID, "confirmation"))
)

Causa 2: estado compartido y orden de prueba

Cuando las pruebas comparten datos, una puede afectar a la otra y el resultado depende del orden en que se ejecutan. Estas dos pruebas utilizan una lista compartida:

store = []

def test_add():
    store.append("x")
    assert len(store) == 1

def test_empty():
    assert store == []

Nuestra ejecución confirmó esto, y es por eso que una suite puede pasar meses y luego fallar cuando alguien agrega ejecuciones paralelas o un complemento de orden aleatorio. La cura es el aislamiento:

• Proporcione a cada prueba datos nuevos, utilizando un dispositivo que los configure y los limpie. Nuestro tutorial de pytest muestra cómo hacerlo.
• Cree registros únicos, como un correo electrónico con un sufijo aleatorio, en lugar de un “usuario de prueba” compartido.
• Envuelva las pruebas de la base de datos en una transacción y revertirlas, donde su configuración lo permita.
• Realice pruebas en orden aleatorio con regularidad, para que estos problemas aparezcan temprano.

Causa 3: Fechas, zonas horarias y aleatoriedad

Un examen que se aprueba toda la semana puede suspender un sábado, a medianoche o el último día del mes. Haga del tiempo una entrada, en lugar de leer el reloj dentro de su lógica:

def is_weekend(today=None):
    today = today or datetime.date.today()
    return today.weekday() >= 5

is_weekend(datetime.date(2026, 11, 7))   # True  (a Saturday)
is_weekend(datetime.date(2026, 11, 9))   # False (a Monday)

Esas pruebas dan la misma respuesta cualquier día. Del mismo modo, establezca una semilla fija para valores aleatorios en las pruebas y regístrela cuando utilice datos aleatorios para poder reproducir una falla. No asuma un orden particular a partir de conjuntos, diccionarios de fuentes externas o consultas de bases de datos sin ORDER BY.

Causa 4: Selectores frágiles

Una prueba que encuentra un botón con div:nth-child(3) > span falla con cualquier ajuste de diseño y puede fallar solo para algunos tamaños o variantes de pantalla. Prefiera localizadores basados ​​en lo que ven los usuarios o atributos de prueba dedicados. Nuestra guía de Localizadores de dramaturgos explica el orden para probarlos. Las animaciones son otra fuente frecuente de problemas, así que considere desactivarlas en entornos de prueba.

Causa 5: Servicios y redes externos

Si una prueba llama a un proveedor de pagos real o a una API de terceros, entonces su resultado depende del tiempo de actividad y los límites de velocidad de otra persona. Simule esas llamadas para la mayoría de las pruebas y mantenga una pequeña cantidad de verificaciones de contrato separadas contra el servicio real, para poder saber si cambia. Nuestra guía para pruebas unitarias versus pruebas de integración explica cómo dividirlas.

Cómo diagnosticar una prueba escamosa

1. Confírmelo. Ejecute la prueba muchas veces sin cambios. Con pytest, funciona un bucle de shell simple y un complemento como pytest-repeat le brinda --count=100.
2. Registrar evidencia. Guarde registros, capturas de pantalla y seguimientos de cada falla. El visor de huellas de Dramaturgo es particularmente útil aquí.
3. Enfatiza las condiciones. Ejecútalo con CPU limitada, en paralelo o en orden aleatorio. Hacer que se suspenda con más frecuencia hace que sea más fácil estudiar.
4. Pruébelo solo. Si siempre pasa solo pero falla en la suite, sospeche del estado compartido.
5. Busque patrones. Compruebe qué máquinas, horas del día y pruebas vecinas están involucradas.
6. Compruebe el producto. Pregunte honestamente si esto podría ser una condición de carrera real en su aplicación.

¿Los reintentos automáticos son una solución?

Los reintentos son una red de seguridad útil a corto plazo y no son una cura. Un único reintento automático en CI puede mantener el trabajo en movimiento mientras usted investiga, pero una prueba que necesita un reintento para pasar todavía le dice algo. Peor aún, un error de producto real e intermitente que falla el 20% de las veces normalmente pasará desapercibido en un reintento.

Utilice reintentos con estas reglas: limítelos a uno o dos, registre cada prueba que necesite una y trate esa lista como su lista de tareas pendientes. Una prueba informada como “aprobada al reintentar” debería contar como un problema a investigar, no como un éxito.

Un proceso de equipo para pruebas inestables

1. Medir. Realice un seguimiento de qué pruebas fallan y luego pase la misma confirmación. Muchas herramientas de CI y reporteros de pruebas pueden demostrar esto.
2. Cuarentena. Saque una prueba inestable confirmada de la ejecución de bloqueo, para que deje de interrumpir a todos, pero continúe ejecutándola y rastreándola.
3. Asigna un propietario y una fecha límite. Una cuarentena sin fecha límite se convierte en un cementerio.
4. Reparar o eliminar. Si no vale la pena arreglar una prueba, elimínela y verifique que su cobertura aún exista en otros lugares.
5. Prevenir. Ejecute nuevas pruebas varias veces antes de fusionarlas. Una prueba que falla una vez cada cincuenta carreras se detecta mejor ahora que en seis meses.

Trate una prueba inestable como un error con prioridad y no como ruido de fondo. La gravedad y la prioridad también se aplican aquí, como se explica en gravedad frente a prioridad. Si la inestabilidad es generalizada, lea sobre errores de automatización de pruebas más amplios y considere si tiene demasiadas pruebas a nivel del navegador.

Conclusión

Las pruebas inestables parecen aleatorias, pero rara vez lo son. Casi todo el mundo se reduce a una suposición sobre el tiempo, el orden, los datos o el entorno que no siempre es cierta. Elija la prueba que falle con más frecuencia en su proceso esta semana. Ejecútelo cincuenta veces, encuentre la suposición y arréglelo para siempre. Una solución real le enseña a un equipo que más de cien reposiciones lo harán.

Preguntas frecuentes

sigue aprendiendo