3.2. Problemas en pruebas automatizadas

A la hora de hacer pruebas automatizadas, debemos ser cuidadosos en no generar problemas. Si, las pruebas también tienen bugs, lo cual puede sonar un poco desalentador. Pero esto es una realidad, y un motivo que hace que la transición de pruebas manuales a pruebas automáticas sea dolorosa. Entre los tipos más comunes de problemas se encuentran las pruebas que consumen muchos recursos (greedy tests), que son costosas y pueden inducir otros fallos cuando se corren pruebas en paralelo. Por ejemplo, si en una máquina que corre varias pruebas de forma concurrente, una de estas es greedy y consume gran cantidad de memoria, las otras pueden tener problemas en su ejecución por la falta de memoria. Otro tipo de prueba problemática se conoce como "slow test" (muy similar a la greedy); este tipo de prueba de larga ejecución puede reducir el tipo de recursos disponibles (en particular procesador) para otras pruebas.

Sin embargo, el fenómeno de pruebas "problemáticas" más analizado se conoce como flaky test ¹. Algunos scripts y casos de pruebas automatizados son inestables y frágiles a cualquier cambio en el ambiente de ejecución de las pruebas. Con inestables (flaky) queremos decir que la prueba se puede comportar de forma no determinística, y exhibir comportamientos diferentes en cada ejecución, a pesar que el comportamiento debería ser el mismo todas las veces que se ejecuta la prueba (es decir ni la prueba ni el sistema bajo pruebas ha cambiado). Esto puede llevar a que una prueba se catalogue como exitosa o fallida de forma errónea.

Por ejemplo, en el caso de pruebas E2E, un script realiza eventos sobre la GUI y busca que ciertas propiedas en la GUI se cumplan. El script es una secuencia de eventos que se ejecutan directamente sobre la interfaz, donde cada evento podría generar un cambio en la GUI. Estos cambios requieren que la aplicación se repinte, se ejecute un proceso del lado del servidor, o se espere a una respuesta de algún componente. ¿Los tiempos de respuesta, repintado, ejecución son los mismos siempre? NO. Esto puede llevar a que si el script tiene un tiempo de espera entre eventos (o timeout) quemado en código (ej., Thread.sleep(5000), driver.sleep(5000)) y este tiempo no coincide con el tiempo de respuesta de la aplicación, la ejecución de los eventos no va a estar coordinada con el estado de la app. Si la prueba va a ejecutar una acción sobre el botón "Aceptar" y el botón no ha aparecido aún en la GUI, pues la prueba va a generar un error. ¿Pero por qué puede pasar esto? Sencillo, las ejecuciones de aplicaciones no son determinísticas, y el asumir tiempos errores de respuesta puede llevar a pruebas inestables. Ejemplos de elementos reconocidos en la industria y la academia como generadores de pruebas flaky son:

• fallas en el hardware
• problemas de configuración del ambiente, motor de integración continua y dependencias
• latencia en la red y conectividad eventual
• sobrecarga de recursos tanto en la máquina que corre las pruebas como en la que ejecuta la app
• carga y concurrencia actual de la app bajo pruebas
• condiciones de ejecución (race conditions)
• problemas de desempeño en la app bajo pruebas
• datos/cache que se mantiene de pruebas anteriores

Un escenario común al hacer pruebas (móviles o web) es lanzar múltiples browsers or emuladores en la misma máquina para sacar provecho de los múltiples procesadores. Sin embargo, las máquinas tiene una cota superior a partir del cual el rendimiento empieza a decaer. Lanzar y ejecutar más emuladores/browsers lleva a que los tiempos de respuesta y procesamiento decaigan, con lo cual se aumenta la probabilidad de tener pruebas flaky.

¿Cómo se pueden detectar las pruebas "flaky"? Una heuristica sencilla consiste en ejecutar la prueba múltiples veces; si en alguna ejecución el resultado es diferente (asumiendo que el resultado debe ser siempre el mismo), entonces estamos hablando de una prueba flaky que debe ser revisada. Si se sigue un enfoque de pruebas con mútiples ejecuciones se aumenta la probabilidad de encontrar pruebas flaky (y sus razones) y de tomar una acción correctiva de forma temprana.

El artículo de John Micco (Google) titulado Flaky Tests at Google and How We Mitigate Them, brevemente describe la realidad de flaky tests en google y que acciones realizan para su detección y mitigación.

¿Cómo se evitan las pruebas "flaky"? En el caso de usar APIs de automatización que no auto-detectan cuándo la app está en estado idle (es decir, en espera para un nuevo evento), se deben usar timeouts grandes, con efecto colateral en la duración de las pruebas. Otra opción es implementar mecanismos propios de detección. Independientemente de la API, se deben reducir al máximo cualquier elemento que pueda introducir latencia durante las pruebas.

¿Qué tiene que ver esto con headless testing? En la siguiente sección te daremos la respuesta.

¹. Qingzhou Luo, Farah Hariri, Lamyaa Eloussi, and Darko Marinov. 2014. An empirical analysis of flaky tests. In Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering (FSE 2014). ACM, New York, NY, USA, 643-653. DOI: https://doi.org/10.1145/2635868.2635920 ↩