¿Qué es Lippia?
Lippia es un Framework que permite automatizar pruebas en aplicaciones Web, Mobile, Desktop y APIs.
El nombre Lippia proviene del nombre de una flor argentina y sus pétalos representan los distintos componentes del Framework.
Lippia es un Framework que utiliza BDD (Cucumber), puede integrarse a Jenkins, funciona con Selenium para automatizar web, Appium para aplicaciones mobile, y también sirve para automatizar aplicaciones de escritorio escritas en Java y APIs REST. Por otro lado, emite reportes y puede portarse dentro de un contenedor Docker o Kubernetes.
En la web de Lippia (https://lippia.io) van a poder encontrar códigos de ejemplo para automatizar web, mobile, apis o aplicaciones de escritorio.
En esta pequeña guía, voy a explicar como poner en marcha el ejemplo WEB. Para ello, clickeamos en “Lippia Web Sample Project” y nos llevará a su repositorio en GitHub.
Una vez en GitHub podemos clonar el repositorio o bajarlo como zip. Yo en este caso lo voy a descargar
Una vez que tenemos descargado Lippia, lo descomprimimos y abrimos nuestro IDE. Yo utilizo IntelliJ porque me resulta muy cómodo, pero pueden usar el que más les gusta.
Vamos a FILE >> OPEN y buscamos la carpeta descomprimida. Una vez abierta, ya tendremos el framewok listo para empezarlo a trabajar.
Estructura del Framework:
Lippia tiene varias partes, pero 3 son las fundamentales a la hora de trabajar automatizando. Ellas son:
- Features (Secuencia de pasos escritos en lenguaje coloquial)
- Steps (Traducción de lenguaje coloquial a lenguaje de programación)
- Page Object (Métodos y mapeos)
El Feature es en donde tendremos el escenario escrito en lenguaje coloquial (Cucumber)
Cucumber es una herramienta utilizada para implementar metodologías como BDD (Behaviour Driven Development) las cuales permiten ejecutar descripciones funcionales escritas en texto plano como pruebas de software automatizadas.
Estas descripciones funcionales, se escriben en un lenguaje específico y legible llamado «Gherkin”, el cual sirve como documentación al desarrollo y para las pruebas automatizadas.
Estos ficheros deben tener extensión «.feature». Cada feature está compuesto por un Background (opcional si se requieren pasos previos antes de ejecutar los escenarios) y por 1 a N escenarios.
Cucumber tiene palabras reservadas como GIVEN, WHEN, THEN, AND, entre otros que no son tan usuales, como por ejemplo BUT
En este ejemplo, veremos como hacer una búsqueda en Google, por lo que nuestro feature sería así:
1 | Feature: Como usuario de underc0de, quiero buscar la web en Google |
@Smoke
Scenario: El usuario busca por “Underc0de” en Google
Given El usuario esta en la web de Google
When El usuario busca la palabra underc0de
Then El usuario ve los resultados de la busqueda
Given: Dado
When: Cuando
Then: Entonces
La otra parte son los STEPS. El archivo de steps contiene cada línea de nuestro feature convertida a lenguaje de programación y acá es en donde le decimos que acciones debe ejecutar nuestro script.
1 2 3 4 5 | @When("El usuario busca la palabra (.*)") public void search(String criteria){ homePage.enterSearchCriteria(criteria); homePage.clickSearchButton(); } |
En esta porción de código estamos indicando las acciones que debería hacer el paso de “Buscar la palabra underc0de en Google”
Por último, tenemos los Page Object, en esta parte, se encuentran los mapeos y los métodos. Para explicarlo mejor (porque suele ser confuso al principio), podemos decir que el MAPEO, es en donde guardamos dentro de una variable, como se llama el elemento de la web. Es decir, si estamos en el buscador de Google, en una variable que se llame “Buscador” pondremos el nombre de la barra de buscar.
Pero… ¿De qué forma hacemos esto?
Existen varias formas de mapear un elemento. Puede hacerse por medio del ID, CLASS, NAME, XPATH, entre otros… Aunque esos 4 son los más comunes.
Y… ¿En dónde encontramos esos atributos?
En su código fuente. Para ello, vamos al buscador de Google e inspeccionamos el elemento (Click derecho en la barra de búsqueda >> Inspeccionar elemento)
Al dar click en “Inspeccionar elemento” se nos abrirá el inspector, y resaltado en azul, estará el pedazo de código correspondiente a lo que estamos analizando. En este caso se resalta un INPUT que es la barra de búsqueda.
Dentro de esta etiqueta, podemos ver varios atributos, como por ejemplo su CLASS, el NAME, entre otros… Pero como dijimos antes, los más comunes son los 4 mencionados anteriormente.
Para poder saber cual es su XPATH, simplemente damos click derecho en el código resaltado en azul y ponemos COPIAR >> XPATH
El XPATH representa la ubicación de ese elemento en el DOM del sitio. En este caso, el XPATH del INPUT es: /html/body/div/div[2]/form/div[2]/div[1]/div[1]/div/div[2]/input
Se ve un poco confuso, pero es básicamente el árbol en donde se encuentra localizado ese INPUT, es decir, todo código HTML empieza con la etiqueta HTML, luego tiene un BODY y dentro del body hay DIVs que son contenedores de elementos. Ese XPATH representa toda esa estructura hasta llegar al INPUT.
NO ES RECOMENDABLE USAR XPATH PARA AUTOMATIZAR. Lo remarco en mayúsculas porque si agregan un nuevo contenedor (div) o mueven de lugar ese input, el XPATH cambiará y nuestro código quedará obsoleto y deberemos refactorizarlo.
En cambio, si utilizamos otro tipo de locator, es difícil de que se rompa nuestro código salvo de que agreguen otro con el mismo nombre.
Por lo general, los IDs suelen ser únicos por elemento, por página. Por lo que, si agregan un segundo INPUT, no debería llamarse igual al primero y nuestro código seguiría siendo funcional.
Sabiendo todo esto, podemos volver al principio y decir que un Page Object contiene ese mapeo de elementos (guardados en variables) y los métodos. El método es en la parte en donde le decimos que debe hacer nuestra solución con ese elemento. Es decir, si debe clickearlo, ingresar algún valor, verificarlo, etc.
Sabiendo estos 3 pilares del framework (Que de hecho casi todos los frameworks poseen la misma estructura), podemos seguir avanzando y ver cómo funciona.
FEATURE
En nuestro feature, indicamos en lenguaje coloquial y utilizando las palabras reservadas GIVEN, WHEN, THEN, que es lo que debería hacer nuestro script.
En otras palabras, esto quiere decir:
DADO que un usuario esta en Google, CUANDO busca la palabra underc0de, ENTONCES se muestran los resultados correctamente.
Hay 2 cosas más que es necesario aclarar acá. Por un lado hay un @Smoke en amarillo en la línea 3. Esto quiere decir que pertenece a la suite de test cases del Smoke. Podemos ponerle cualquier nombre, es simplemente un TAG, y sirve para indicarle al framework que test cases debe ejecutar. Si tenemos 10 test cases con el tag @Smoke, entonces correrá esos 10 test cases uno detrás del otro.
Y lo otro que hay que aclarar, es que la palabra underc0de aparece en azul. Y esto es porque lo estamos tratando como variable. Esto sirve para reutilizar código más adelante. Es decir, si queremos buscar Underc0de, y luego queremos buscar “Hacking, Programación, etc” podemos utilizar siempre el mismo STEP que es lo que veremos a continuación.
STEPS
Como dijimos antes, en el step se encuentra la traducción del Gherkins a lenguaje de programación.
Cada step, comienza con la etiqueta correspondiente (la misma que el Gherkins) @Given, @When, @Then y dentro la serie de pasos que debe realizar ese paso en particular.
Cada step, puede realizar 1 o N pasos (en lo posible no muchos, para poder identificar en que falla en caso de que tire alguno un error)
Estos Steps, al mismo tiempo, llaman a un método del Page Object (Que son los que tienen las acciones que deben realizar)
PAGE OBJECT
La teoría de Page Object dice que CADA PAGINA, DEBE TENER SU PROPIO PAGE OBJECT. Es decir, el login tendrá el suyo, el registro tendrá el suyo y así con cada página que tenga la aplicación.
Como ya expliqué antes, esta contiene el mapeo de los elementos (Lineas 8 y 9 de la imagen) y también los métodos (acciones que se realizarán en cada uno de esos elementos mapeados).
En los métodos, debemos indicar por medio de que atributo lo estamos localizando, en este caso se puede ver que al INPUT lo estoy localizando por el XPATH y al botón buscar por el NAME.
POM.XML
Este archivo contiene algunas propiedades, como por ejemplo, el TAG de ejecución
Como se puede ver en la línea resaltada (Línea 18) el framework correrá todos los tests que tengan el tag @Smoke
TESTNG.XML
Por último, para correr los test, debemos darle click derecho al archivo TESTNG.XML >> RUN
Y esto correrá el test de buscar underc0de en Google
Una vez ejecutado, podemos ver los resultados de la ejecución en la consola o en el reporte que genera el framewok. El reporte esta ubicado en:
TARGET >> CUCUMBER-REPORT >> EXAMPLE.HTML
Lo abrimos con nuestro browser de preferencia y podremos ver el reporte de la ejecución:
En caso de fallar, indica el error y adjunta una captura de pantalla, como a continuación:
Lo que hice fue cambiar el valor en un elemento del page object (en el mapeo) para que no encontrara y tirara este error de que no encontró el elemento.
.PROPERTIES
Por último, tenemos las “properties”, acá se indican algunos parámetros como por ejemplo en que browser se correrán las pruebas, en que tamaño abrirá el browser, tiempos de timeout para encontrar un elemento, etc.
Esto es todo por ahora! Espero que les guste Lippia, y cualquier duda que tengan, pueden dejarla en los comentarios!
Saludos
ANTRAX
