top of page

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.