Lippia, un Framework Multipropósito

Iniciado por ZarathuxXxtrA, Junio 01, 2020, 08:08:02 PM

Tema anterior - Siguiente tema

0 Miembros y 1 Visitante están viendo este tema.

Junio 01, 2020, 08:08:02 PM Ultima modificación: Junio 01, 2020, 09:22:59 PM por ZarathuxXxtrA

Que significa el nombre Lippia en latín? Es el nombre científico de Lippia integrifolia, planta vulgarmente conocida en América del sur como Incayuyo. Muy utilizada para infusiones en la provincia de Córdoba Argentina.

El proyecto en sus inicios, según cuenta su fundador Javier Ré conjuntamente con el equipo de CROWDAR, habría de llamarse Incayuyo pero al no ser un nombre comercial, decidieron bautizarlo con el que lo conocemos actualmente al Framework: Lippia.

A muy grandes rasgos, sin ahondar en lo técnico, Lippia es un Framework multipropósito. Pero antes de avanzar en su descripción, a los autores de dicho framework les interesa comunicar el análisis que se plantearon en sus inicios, con algunas preguntas fundamentales: ¿Qué es lo que nos pasó? ¿Por qué hicimos esto? ¿Dónde llegamos? ¿Dónde queremos ir hacia el futuro?

El nuevo paradigma en materia de testing convoca a los siguientes items:


  • *DevOps
      +Performance
      +Rapid recovery
      +Releases más rápidos
      +CI/CD
  • *Tests en producción
    *Full tolerance
    *Performance


Por lo tanto, a pesar de que en automation hay muchos frameworks, quien quiera puede armarse un propio framework; la premisa de Crowdar era desarrollar algo que permitiera arrancar rápidamente con cualquier cliente.

En una línea cronológica Crowdar fue transitando diferentes estadíos en cuanto a implementaciones, definiendo en función de sus necesidades diferentes soluciones que con el correr de los tiempos, la demanda y actualización tecnológica desembocó en lo que hoy disponemos como herramienta fundamental: Lippia Framework.


Al ser QTP/UFT implementaciones de plataforma comercial, su costo es demasiado caro y, salvo las entidades bancarias, casi nadie contrata QTP por su excesivo costo. Entonces en Crowdar empezó a surgir la necesidad de desarrollar algo que permitiera la posibilidad de seguir realizando testing sin la necesidad de pagar una fortuna en licencias ni obligar a los clientes que compren QTP/UFT.

Se inició un camino de experimentación con herramientas OpenSource. Primero se probó SpecFlow (2016) en un proyecto BDD para .Net, y en la implementación de SpecFlow con Azure DevOps no se obtuvieron resultados satisfactorios. Después de recibir el asesoramiento de diferentes colaboradores probaron integrar en un nuevo diseño Jbehave, proponiéndose construir cosas nuevas.

Luego de probar todo lo que había disponible en el mercado, desembocaron en la consigna de no poder armar un framework distinto en cada cliente asignado. Por lo tanto se fijó la meta de construir algo que permitiera arrancar rápidamente y que el cliente no tenga que esperar tres o cuatro meses hasta que se construyera el framework para poder empezar a automatizar.

Empezaron a elegir herramientas que ya existían en el mercado; Javier Re recordaba de una charla: "...Innovar no es sólo inventar algo nuevo ni muy revolucionario, sino que a veces innovar es tomar cosas que ya existen y usarlas de otra manera, y hacer algo distinto con eso...".  Y eso fue lo que hicieron con Lippia. Empezaron a tomar los principales frameworks opensources existentes en la industria como Cucumber o Appium, siendo Selenium el apoyo primordial para esta búsqueda de innovar en una solución integral.

De esa forma los fueron combinando. Además, con la forma en la que fue evolucionando la tecnología y los tiempos escasos para deployar e instalar un entorno dónde no haya que estar días instalando en alguna plataforma, surgió la idea de introducir un comando y que levante toda la infraestructura.

Apoyado en esa premisa se integró Docker y Kubernetes. La solución estaba en conjugar Kubernetes, Cucumber o Appium, siendo la premisa: "tener algo que funcione, que sea confiable y que pueda escalar principalmente".

Unos de los grandes problemas que se encuentran mucho en la actualidad es que se hacen Frameworks muy completos, pero sólo funcionan en las máquinas de quienes lo desarrollan. Y más si eso hay que escalarlo a servidores que puedan testear con mucho volumen y en entornos complejos.

Timelapse: China construye un edificio de 57 pisos en 19 días

El concepto que hay detrás de ese video es que son bloques. Cada habitación, cada piso es un bloque que se encastra arriba de otro. Cuando se termina un piso, mientras se acondiciona el interior ya se está preparando un piso nuevo superior. Pero es todo armado con bloques como si fuera un lego. Y lo que hizo Crowdar es aplicar ese concepto, tomar todas las herramientas de las que está compuesto Lippia Framework, combinarlas acertadamente, y empezar a aplicar distintas alternativas.

Entonces ¿que puede hacer Lippia Framework? Básicamente puede tomar un stack completo para testear Web, por ejemplo. Entonces Lippia va a levantar contenedores para testear web. Un Selenium Hub, docker containers para los browsers y Lippia posee un Jenkins incorporado. Con todo esto ya se tiene una caja lista para testear cualquier aplicación web sin ningún problema.

Si se quisiera testear Mobile, Lippia levanta contenedores con Appium y devices, en particular Android que es hasta el momento lo que se ha podido dockerizar. Y así en función de cada testeo a medida que queramos realizar, podemos ir eligiendo qué levantar y qué bajar, según necesidades específicas.

¿Qué permite esto? Lippia es un Framework Multipropósito, que en una misma arquitectura se puede testear casi cualquier tipo de aplicación. Obviamente existirán aplicaciones que no se puedan testear, pero el 90% de lo que existe en el mercado actual se puede automatizar con Lippia.

Lo otra particularidad del Framework es que es escalable, es decir, no sólo quiero un framework que corra en mi equipo, sino que quiero un framework que corra además en un sevidor de Integración Continua también. Y en el abanico de oportunidades y recursos que existen, Crowdar eligió dockerizar todo el framework de testing automatizado y subirlo a distintos contenedores. Éste framework por lo tanto correrá en cualquier tipo de máquina sin ningún tipo de problema (con una máquina suficientemente robusta para hacer eso). Y el mismo código, y la misma infraestructura dockerizada, ahora se puede llevar a la nube. Con eso se da la garantía de lo que funciona en "mi máquina" funcione en un servidor también.


Algunas conclusiones y aprendizaje de todo esto:

* Ahorro de tiempo. En otra época todo se establecía para cierto cliente, se creaba un framework a medida, se adaptaba y dejaba funcionando. Y recién después de eso se empezaba a automatizar. Todo eso podía transcurrir entre tres o cuatro meses de iniciado el proyecto. Hoy un cliente nuevo que arranca con Lippia, en dos días empieza a automatizar. Tan sólo es conseguir el servidor, deployar la infraestructura y empezar a automatizar.

Obviamente que hay que saber usarlo, pero cualquiera con conocimientos intermedio de Selenium, que conozca Cucumber y el resto de herramientas mencionadas anteriormente lo puede hacer.


* Multiplataforma y escalable.

* Framework to many apps. Podemos resolver con un sólo framework el testing automatizado de muchísimas aplicaciones.

* Building Blocks. Podemos levantar un bloque, bajarlo y usar lo que necesite.


* Ejecuciones en paralelo, a veces las aplicaciones tienen implicancias complejas, y cuando las empezás a automatizar, empiezan a ser lentas las ejecuciones. Entonces al poder ejecutar test en paralelo, esas ejecuciones corren mucho más rápido, sobre todo si el volumen de test es muy amplio.

* Devices incluídos. Existen muchas plataformas de devices en la nube, para probar distintos dispositivos. Lippia Framework ya entrega devices preconfigurados, y se pueden configurar más aún porque son contenedores docker. Se puede elegir modelo y marca, sólo habrá que realizar alguna configuración básica.

Por supuesto todo esto no reemplaza al testing sobre algún dispositivo real, pero sí escala las pruebas automatizadas que se realizan cotidianamente en cualquier proyecto, y así poder ganar tiempo y recursos. Una no reemplaza la otra, pero complementadas se realiza mucho más rápido cualquier tipo de proyecto.

Lippia usa BDD que, a pesar de que agrega un overhead al proceso de automation, es una buena herramienta para comunicar y para encontrar errores.


* Bajo acoplamiento: Esto significa que no se precisan todos los componentes del framework para poder funcionar. Es flexible al momento de levantar los recursos precisos, y el resto no usarlo. En algunos casos se podrá hasta testear mobile y web con una misma implementación, sin tener que duplicar ese test en el código.

Para Crowdar fue un proceso y un aprendizaje el ponerse como meta realizar Lippia. Absorbieron un montón de incumbencias y competencias para confluir en una comunidad de DevOps que sugirieron y asesoraron. Conociendo lo complejo y fantástico que es Docker, hay que hacerlo andar en producción, y hacerlo andar bien. Todo esto llevó al equipo de Crowdar a asimilar muchísimas nuevas técnicas que a la actualidad enriquecen el rol de un tester. Hoy en día un profesional tester es, (o debería) ser un perfil mucho más técnico. No sólo para programar, sino que también entender lo que sucede en el background de los procesos ejecutados, pudiendo tener objetivos mucho más complejos y que se adapten a las necesidades del mercado o de customización del perfil personal.

Por último, Lippia está abierto a la comunidad, al nivel open source. En Github se pueden encontrar ejemplos en el repositorio de Crowdar (No tienes permitido ver los links. Registrarse o Entrar a mi cuenta), que están también publicados en la página de Lippia (No tienes permitido ver los links. Registrarse o Entrar a mi cuenta). Pueden bajar el código, levantarlo. Hacerlo andar, probarlo y dar feedback en StackOverflow(No tienes permitido ver los links. Registrarse o Entrar a mi cuenta), que es donde se está dando soporte técnico y respondiendo consultas.

Lo que se viene de parte de Crowdar: Están realizando algo similar con Performance. Según relata Javier Re, Performance es un nicho bastante simple y complicado a la vez ya que al día de hoy se observa mucha implementación "receta casera", donde se puede democratizar y escalar mucho usando containers de tecnología que ya existen: JMeter, Jenkins, Grafana; herramientas robustas y opensource que al combinarlas se obtienen soluciones y recursos muy potentes. Otro punto álgido es en base a los aspectos nativos de Appium, y la existencia de capabilities en las que se podría conectar con granjas de devices virtuales como aws(que es un cloud mucho más restrictivo y riguroso) o browserstack; pero lo interesante es la incorporación de Android, para después escalar a los dispositivos físicos y de forma totalmente gratuita.

Sin más, me despido y espero les haya parecido un primer abordaje confortable. ¡Nos leemos en las próximas entradas!
No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
Lo abstracto. El elemento sin el cual, no existiría el camino del guerrero, ni guerrero alguno en busca de Conocimiento.