Respuesta.

La automatización de pruebas comenzó históricamente con la idea de aumentar la velocidad y reducir el factor humano en las verificaciones, sin embargo, pronto se descubrió que las pruebas automáticas a menudo se comportan de manera diferente en cada ejecución. La repetibilidad (repeatability) y la determinación (determinism) son uno de los requisitos básicos de calidad para las pruebas automáticas, las cuales deben ofrecer el mismo resultado bajo las mismas condiciones.

Los problemas comienzan debido a dependencias implícitas: datos de prueba inestables, entornos desincronizados, procesos paralelos o servicios externos. Esto conduce a pruebas inestables (flaky tests) — sus resultados son impredecibles.

Las soluciones se centran en un control estricto del entorno de ejecución, aislamiento de pruebas, objetos mock/stub, datos estáticos y escenarios reproducibles (por ejemplo, limpieza y preparación de la base de datos antes de cada prueba).

Características clave:

Control de los datos de prueba y una inicialización predecible del entorno de pruebas.
Aislamiento de las pruebas unas de otras y abandono de las dependencias entre pruebas.
Uso de objetos Mock/Stub para trabajar con servicios inestables o externos.

Preguntas trampa.

¿Qué hacer si las pruebas inestables ocurren solo en CI, mientras que localmente todo es estable?

Esto casi siempre está relacionado con diferencias en los entornos: versiones de dependencias, velocidad del trabajo de la infraestructura, paralelismo, configuraciones del sistema operativo o el orden de ejecución de las pruebas. La solución es acercar lo más posible el entorno de CI a la máquina de desarrollo (Docker, valores de semillas iguales, configuración de setUp/tearDown en las pruebas).

¿Se pueden considerar las pruebas parametrizadas completamente determinísticas si los datos provienen de una base de datos?

No. Incluso si los datos coinciden en su base, la base de datos puede cambiar entre pruebas o entre lanzamientos. Para una verdadera determinación, los datos deben ser preparados y limpiados explícitamente en cada prueba.

¿Utilizar sleep para esperar la carga de elementos resolverá el problema de inestabilidad de las pruebas de UI?

No. Sleep solo enmascara el problema y ralentiza la ejecución de las pruebas. Es correcto utilizar esperas explícitas (Explicit Waits), que esperan condiciones específicas y no un tiempo fijo.

Errores típicos y anti-patrones

Uso de "números mágicos" y retrasos en lugar de la sincronización adecuada.
Dependencia entre pruebas o cambios en el estado del entorno no revertidos entre las pruebas.
Mezcla de datos de prueba entre escenarios.

Ejemplo de la vida real

Caso negativo

En el proyecto se ejecutaban pruebas de UI en un entorno que nadie limpiaba después de las pruebas manuales. De vez en cuando, las pruebas fallaban con errores "aleatorios" que no estaban presentes localmente. El equipo agregó sleep a las pruebas e ignoró los problemas flaky.

Ventajas:

No fue necesario gastar mucho tiempo en la solución raíz del problema.
Las pruebas a veces aún permitían encontrar errores.

Desventajas:

Costo de tiempo en re-ejecuciones.
Resultados negativos falsos desmotivaron a los ingenieros.
Los informes se cubrían de ruido, y la verdadera regresión podía ser pasada por alto.

Caso positivo

Después de la llegada de un ingeniero DevOps maduro, el equipo implementó scripts para restablecer e inicializar los datos de prueba, agregó servicios mock para integraciones inestables y comenzó a ejecutar pruebas en contenedores. Las pruebas inestables prácticamente desaparecieron.