Finite State Machines y Automation: Revolucionario o una mala idea?


Hace unos años incursioné en el desarrollo de videojuegos. Nada loco, era yo solo, así que se imaginarán que no fue muy ambicioso ese primer proyecto.


Café y código
No todas las ideas son buenas...o si?

Resulta que el proyecto, hecho con Unity y C#, era un scroller automático en el que el usuario tomaba decisiones y esas decisiones iban llenando distintas barras. Al llegar a x valores en cada barra, aparecían determinados eventos y, cuando se llenaba una, había una especie de "lucha" con un jefe que no era ni más ni menos que un Piedra Papel o Tijera.


Qué tiene que ver todo esto? Bueno, ahí fue donde implementé, por primera vez, una state machine finita. Cómo? Bueno, mientras el usuario estaba con un evento y tenía que responder éste estaba en un "estado". Cuando estaba peleando con un jefe, otro "estado", mientras caminaba, otro "estado".


Por años me pregunté: Qué pasa si implemento algo similar pero para Automation Testing? Hacer una especie de bot "inteligente" que haga una u otra cosa y testee? Bueno, en este artículo vamos a hablar un poco de la teoría que tengo y por qué puede que sea una mala idea!


Qué problema estaríamos resolviendo?


Bueno, si les soy sincero, no fue lo primero que pensé. La idea apareció como un desafío técnico más que una solución. Eso ya de por si la hace posiblemente una mala idea (aunque no para aprender). Pero, pongámosle onda y pensemos qué beneficios tendríamos si tuviésemos algo así:

  1. Un solo punto de entrada que se encarga de probar todo.

  2. Reacciona a los cambios y lo hace de forma inteligente.

  3. Puede estar corriendo de forma indeterminada.

Vamos a analizar cada punto a ver si hay algún fundamento o si soy yo sobrecafeinado hablando. Vamos con el primer punto. Si, es cierto que sería un solo punto de entrada y se encargaría de probar todo recorriendo de forma inteligente las posibles ramificaciones en el comportamiento del sistema. La desventaja? Cómo damos visibilidad a lo que se probó y lo que no? Se podría resolver introduciendo logs donde queremos comunicar algo. Lo dejo a la imaginación de ustedes!


FSM
Un simple diagrama de un FSM

El segundo punto habla de reaccionar a los cambios de forma inteligente. Si, podría ser una ventaja y, siempre que hablo de este tipo de testing, creo que lo haría desde un lugar de "exploratory testing automatizado" ponele, más que un reemplazo a las capas de testing referidas a integration, E2E, UI Testing. La desventaja? El mantenimiento futuro de algo así podría convertirse en una bestia difícil de domar. Cuando tengamos un sistema automatizado con cientos de interacciones, decenas de estados y se introduce nuevos de estos, analizar qué otros ciclos se ven impactadnos y actualizar todo de forma acorde podría ser un auténtico dolor de cabeza.


El tercer punto es uno sencillo. La idea sería tener este "bot" escuchando por cambios y que corra siempre que se introduce uno. Sin tener que "lanzar" la ejecución, sea con webhooks al repositorio, con CRON en una herramienta de CI como Jenkins... no, no. Acá hablamos de un bot que escucha directamente al sistema que prueba y que cuando hay un cambio, el estado pasa al inicio del ciclo de testing.


Los desafíos técnicos.


Bueno, hay una idea. Ahora...cómo la llevamos a cabo? Deberíamos tener un sistema en mi opinión, E2E, capaz de modificar el BE de la aplicación para dejar todo listo en cada estado en el que entramos. Para eso, se me ocurre usar algo como Cypress posiblemente. Podríamos optar por Selenium acompañado de una librería para lidiar con APIs si no queremos usar Cypress.


Ahora, deberíamos definir un "listener" que esté atento a cambios en el sistema para volver al estado original y empezar desde ahí. También deberíamos definir qué pasa cuando se llega al final del ciclo de estados. Volvemos al principio con otros datos? Dónde tendríamos corriendo esto las 24hs? De forma local es mala idea, un container quizás que levantemos como instancia junto al ambiente de pruebas en otro y hablando entre ellos con Docker Compose?


Como ven, hay muchas partes inciertas y, posiblemente, muchos puntos en los que vamos a descubrir que era una pésima idea o que había desafíos que ni siquiera habíamos considerado.


Conclusión


Puede ser un lindo proyecto para aprender a plasmar ideas en código y no simplemente seguir un framework para los que empiezan en Automation y quieren moverse al ámbito del SDET. Me pregunto...alguien dispuesto a tomar este desafío? Por otro lado, qué rol creen ustedes que cumpliría una herramienta de este tipo en lo que hace a la calidad de un sistema? Los leo!

20 visualizaciones0 comentarios

Entradas Recientes

Ver todo