Respuesta.

El mecanismo de reejecución de pruebas (retry) se implementa con el objetivo de aumentar la estabilidad del pipeline de pruebas y combatir las pruebas automáticas inestables, pero requiere un enfoque razonable.

Historia del tema Apareció como un workaround para errores temporales de infraestructura o errores inestables, no relacionados con errores de la aplicación (entorno inestable, problemas de red, timeouts aleatorios de API). Muchos sistemas de CI/CD ahora soportan un retry integrado.

Problema Un retry excesivo o incontrolado puede ocultar errores reales o hacer que las caídas se conviertan en "simplemente fenómenos temporales". Aparecen resultados falsos positivos: parece que la prueba pasó, pero el error sigue existiendo.

Solución Activa el retry solo para pruebas inestables o dependientes de externos, utiliza etiquetas o marcadores. Límite fijo de reintentos (1-2 veces). Registra todas las caídas y éxitos de las reejecuciones para analizar las causas de los fallos.

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # Prueba que puede fallar debido a la inestabilidad de la API
    ...

Características clave:

Aplicar de manera puntual y consciente
Siempre analizar las causas de los reintentos
No enmascarar errores de la aplicación, sino solo problemas de infraestructura/inestables

Preguntas capciosas.

¿Se puede hacer un reinicio de absolutamente todas las pruebas automatizadas en el pipeline?

Es una mala práctica: se ocultan tanto errores reales como problemas arquitectónicos de las pruebas. El retry es un último recurso para ciertos tipos de pruebas.

¿Qué hacer si después de 3 reintentos la prueba aún no pasa?

Detener la ejecución y abrir un bug por inestabilidad/investigación: así se identifican errores difíciles que requieren refactorización.

¿Si la prueba pasa en el segundo intento, significa que todo está bien?

No, el único estado correcto es pasar de manera estable en el primer intento. Pasar en el segundo es un indicador de problema (inestabilidad o infraestructura).

Errores comunes y anti-patrones

Aplicación incontrolada del retry, ocultando errores
Falta de análisis de las causas de las caídas
Uso de retry en lugar de solucionar problemas reales

Ejemplo de la vida real

Caso negativo

Se activó un retry global para todo el pipeline de Jenkins para dos ejecuciones. Después de un mes, los bugs debido a condiciones de carrera en el código se ocultaron, y el equipo pensó que "la calidad estaba bien". El producto de repente comenzó a caer en producción debido a los mismos errores.

Pros:

Hubo pipelines verdes

Contras:

Los errores de la aplicación no se identificaron a tiempo
Al investigar, es difícil entender la fuente de la inestabilidad

Caso positivo

Para la categoría de pruebas con APIs externas, se configuró retry solo para ellas (por etiquetas). Todas las demás pruebas pasan estrictamente con un solo intento. A través de los registros, el equipo investiga y soluciona fallos repetidos.