Te va a interesar!

6/recent/ticker-posts

Templates en Automation: Por qué es buena idea tenerlos.

Imaginate que te asignaron la creación de tests automatizados para una aplicación en particular dentro de la empresa en la que trabajás. Te arremangaste, decidiste usar Gradle con Java y RestAssured para los tests de APIs y Selenium para los de UI. Configuraste la clase base que van a heredar las páginas del Page Object Model, la creación del Driver, la configuración de cómo querés que se comporte, la configuración de un proxy o el otro, el uso o no de Keystore y TrustStore para las requests a un endpoint con Mutual TLS, el Runner para Cucumber, la estructura del proyecto,

Perfecto, tenés todo listo para empezar a trabajar en la creación de tests automatizados! A los pocos meses, te piden que hagas lo mismo pero para otra aplicación interna de la empresa. Por cuestiones de prolijidad, se requiere que lo hagas en un proyecto aparte, para evitar que un proyecto maneje la responsabilidad de testear distintas aplicaciones. Lógico. Pero ahora vos tenés que hacer todo lo que hiciste antes de nuevo! Y si, ya sabés cómo hacerlo. Quizás te olvides de algunos detalles en el camino, vayas de nuevo al proyecto que creaste antes para acordarte cómo era...en fin, una pérdida de tiempo en mi opinión.

Qué tal si, en lugar de este flujo de trabajo, creamos unos Templates para que empezar a automatizar una nueva aplicación sea un paseo y no tengamos que perder tiempo con toda la configuración del Framework desde cero? De eso trata este post!

Primero que nada...¿Qué es un template cuando hablamos de Automation?

En este caso me refiero, lisa y llanamente, a tener un proyecto en nuestra herramienta de Source Control Management de preferencia que sirva como lienzo en blanco para empezar a crear, con todas las configuraciones comunes previas necesarias. A ver, lo pongo en otras palabras. 

En lugar de crear desde cero cada proyecto que necesitemos para cada aplicación, nuestro punto de partida va a ser un template que creamos previamente con las herramientas necesarias para empezar a automatizar. Les voy a contar, como suelo hacer, de una experiencia personal relacionada y cómo salió. 

Cuando comencé en el último cliente, tenían un proyecto ENORME. Ese proyecto hacía todo: Se encargaba de hacer bindings con una librería para LDAP, también había wslite para las llamadas REST y SOAP, un poco de Selenium en la ensalada para los tests en UI, millones de clases que eran referidas por otras clases que a su vez daban una vuelta carnero y referían...si si, otras clases. En fin, pueden ver por qué querían practicarle la eutanasia a esta manera de trabajar. 

Lo primero que sugerí e hice demo para convencer a management fue: "Ok, necesitamos crear templates que sean puntos de partida para los distintos proyectos que los equipos empiecen. De esta manera vamos a tener solo lo necesario por proyecto, todos van a estar trabajando bajo un mismo approach y yo, desde el equipo central de Automation, voy a poder ayudarlos sin tener que desenredar ovillos de código para entender qué se estaba queriendo hacer". 

En unos momentos hice el borrador del template para UI. Lo clásico...Selenium con Cucumber (porque lo pedía management, no porque hubiese un BA creando los Features), un TestDataManager, Page Object Model y PageFactory, una clase para manejar la encriptación y el reporte. De ahí se fueron agregando detalles según las necesidades que surgían. Pero ese proyecto siempre quedó como el template al que cualquiera que empieza a automatizar en el cliente se dirige, clona y cambia origen a su propio proyecto. Sin tener que hacer toda la parte molesta de configuración y estando al mismo tiempo alineado con el resto de la empresa. 

Hice lo propio con otro template, pero esta vez para APIs. No quería mezclar API y UI en un mismo framework porque me gusta mantener los tantos separados. Este otro template no iba a tener clases para páginas porque se dedicaba solo a APIs, iba a tener algunas cosas diferentes como la configuración de Keystores y Truststores para Java para poder conectarme a algunos endpoints quisquillosos que pedían certificados específicos, algo para poder validar JSONs como dios manda, XMLs...ustedes saben, un mundo un tanto diferente. 

Así que esto es a lo que me refiero con "templates". Y por qué usarlos? Bueno...vamos a ver cómo sigue esta historia.

Las ventajas de tener templates para las distintas necesidades de Automation en tu cliente/proyecto.

La primera y más obvia ventaja que seguramente ya adivinaron basados en lo previo es que vamos a ahorrar mucho tiempo en el setup de nuevos proyectos de Automation. Al mismo tiempo, vamos a ahorrar mucho tiempo de hacer ingeniería inversa de otros trabajos que nos toquen mantener en un futuro, al evitar hacer las cosas de forma distinta y estar todo alineado debajo de un grupo de decisiones que tomamos a la hora de hacer el template, solos o con nuestro equipo. 

Las mejoras futuras van a ser aplicadas para que todos los futuros usos ya las tengan implementadas aunque, eso si, los que ya hicieron uso del template y quieran gozar de esas mejoras van a tener que implementarlas ellos mismos, por lo que es muy importante tener un buen punto de partida. 

También es importante entender que las mejoras deberían ser agnósticas de las necesidades particulares de un proyecto. Si un proyecto necesita, como les decía, LDAP, mi sugerencia es que no añadan eso al Template ya que es 1 proyecto de 40 va a usar eso nada más. Eso debería ir en la especificación que creen ellos post clonación. 

Si lo piensan detenidamente, es algo similar a cómo manejamos la Abstracción y el Polimorfismo en la Programación Orientada a Objetos, no? Creamos este proyecto que vendría a ser la Abstracción, con lo que va a ser necesario para los demás proyectos, con sus cosas que van a ser implementadas si o si, otras que ya vienen de fábrica como se van a usar...

Y los proyectos van a ser la implementación, el polimorfismo y la extensión de la funcionalidad que creamos en este proyecto abstracto inicial. Me fui un poco por las ramas, lo se. Y de hecho la analogía no termina de cerrarme, pero quizás a alguien le ayude para visualizar a lo que quiero llegar con este post. 

Las desventajas de tener templates...las hay?

Bueno, no se si llamarlas desventajas. Pero lo cierto es que hay escenarios en los que hay que tener cuidado con cómo procedemos. Como les comentaba arriba, cuando surge una mejora al template, mucho tiempo después de su creación y que los proyectos ya lo hayan utilizado como punto de partida el problema que se presenta es el de no tener el template actualizado con las mejoras porque una vez que lo clonaste y le cambiaste el origen, es tratado como un repositorio nuevo. 

Ponerse de acuerdo a veces también puede ser un tema. Yo por ejemplo tuve que luchar mi camino para descartar SpringBoot en favor de Google Guice (con el que tampoco estaba 100% de acuerdo pero, por las necesidades de la mayoría, se terminó implementando) y para utilizar RestAssured en lugar de HTTPMethod metido en un wrapper casero sin sentido. 

También es complicado cuando este cambio de dirección significa tener que retrabajar muchos proyectos viejos para alinearlos con esta nueva visión. Y por qué? Porque una vez se retrabajaron cualquier trabajo de mantenimiento va a ser más llevadero, pero llegar a ese punto puede ser un golpe duro al presupuesto del proyecto. 

Conclusión.

Al mediano y largo plazo, vamos a ver un impacto muy positivo. Tanto en el ánimo de los equipos trabajando, que ya no tienen que lidiar con legacy extraterrestre para entender cómo hacer hasta la cosa más sencilla, como en el tiempo de ejecución y entrega de artefactos de test, que ya no se van a ver demorados con el setup, entender por qué las cosas se hicieron así y un sinfín de problemas!

En mi caso, he visto los resultados de este cambio en el último año y medio y puedo decirles que fue muy bueno. Ahora todo se alinea a la visión desde un equipo de Automation central que lidero, simplificando mucho los pedidos de ayuda de otros equipos ya que se exactamente lo que están usando. Los templates fueron usados para artefactos de lo más curiosos con mucho éxito y management está por demás contento con los tiempos y resultados, así que...por qué no lo probás este approach y me dejás tu comentario?!

Publicar un comentario

2 Comentarios

  1. Buenas,
    Me encantan tus blogs, siempre que tengo un tiempo los leo 🤗
    Yo también aporto desde mi humilde posicion a la comunidad con mi canal de YouTube http://bit.ly/2NVRX7F
    Saludos!! 😃

    ResponderBorrar
    Respuestas
    1. También te sigo en Youtube, está buenísimo lo que hacés! Saludos :)

      Borrar