Respuesta.

Las pruebas flaky son aquellas que pueden pasar o fallar sin cambios en el código, debido a factores externos aleatorios. Socavan la confianza en la automatización y dificultan los procesos de CI/CD.

Historia de la cuestión: La tensión con las pruebas flaky surgió con el aumento de pruebas E2E, de integración y pruebas de UI, cuando la estabilidad del entorno y de los servicios dependientes no estaba garantizada. Al principio, tales fallos se ignoraban o se "reiniciaban manualmente".

Problema:

Las pruebas flaky hacen que la ejecución automática de pruebas sea poco confiable.
Los desarrolladores comienzan a pasar por alto fallos reales, considerándolos falsos.
Aumenta el tiempo de mantenimiento de las pruebas y se requiere un análisis manual de resultados inestables.

Solución:

Conteo separado de pruebas flaky. Etiquetar (por ejemplo, @FlakyTest) o clasificarlas en una categoría separada.
Reejecución automática. En caso de que una prueba falle, repetirla X veces; si no falla siempre, se marca como inestable.
Análisis de las causas de inestabilidad: uso de registros, instantáneas de estado, monitoreo de recursos (por ejemplo, red inestable, colas o funcionamiento del GC).
Corrección gradual: trabajo con el entorno de prueba, simplificación de escenarios, simulación de dependencias inestables.

Ejemplo de código para reintento automático:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # código de prueba

Características clave:

Es importante separar las pruebas flaky de los verdaderos fallos.
No se debe simplemente "reiniciar todo"; los verdaderos errores no deben ser ignorados.
Se analiza y documenta regularmente el estado de la prueba, en lugar de silenciarlo.

Preguntas capciosas.

¿Las pruebas flaky son siempre un problema de infraestructura?

No, las flaky pueden ser causadas por errores de la lógica de negocio, condiciones de carrera en el código, asincronía o un manejo incorrecto del tiempo.

¿Es suficiente simplemente reiniciar las pruebas fallidas?

No, los reintentos solo enmascaran el problema. Es necesario buscar y eliminar la causa.

¿Deberían eliminarse todas las pruebas inestables?

No, deben ser aisladas temporalmente y corregidas las causas, en lugar de ser excluidas para siempre.

Errores comunes y anti-patrones

Ignorar lo flaky, lo que lleva a pasar por alto errores graves.
Reintento masivo sin analizar las causas.
Etiquetar pruebas importantes como flaky sin tomar medidas para corregirlas.

Ejemplo de la vida

Caso negativo

En el proyecto, las pruebas flaky se etiquetaron y no se tocaron más, considerando el problema "insoluble".

Ventajas:

Reducción del número de compilaciones "rojas" falsas.

Desventajas:

Los errores reales llegan a producción.
Verificación manual constante de resultados.

Caso positivo

Para cada prueba inestable, se implementó un reintento automático y un conteo interno de inestabilidad. Se realizaban revisiones conjuntas regulares de las causas y se corregían errores a medida que se acumulaban.