Primera parte click aquí
Continuamos con la segunda parte de Cypress, donde vamos a aprender buenas prácticas utilizando el patrón de diseño page object model, fixtures para nuestros locators, reportes, y finalmente, CI con Azure DevOps Pipelines.
Este patrón de diseño se utiliza en pruebas automatizadas para evitar código repetitivo y mejorar el mantenimiento de las mismas.
Debemos tener en cuenta un punto muy importante al automatizar: la UI (Interfaz de usuario) puede sufrir cambios. Si nuestras pruebas manipulan directamente los elementos de la página, estos serán muy frágiles y requerirán el doble de mantenimiento.
Cuando diseñamos una prueba automatizada para un sitio web debemos localizar sus elementos para hacer una acción, como hacer click en botones y determinar lo que se muestra a continuación. El patrón POM encapsula el comportamiento de las páginas, o una parte de este, con una API específica de la aplicación, lo que nos permite escribir tests y manipular elementos de la página sin tener que lidiar con el HTML. En resumen, el patrón POM se usa para hacer pruebas funcionales automatizadas. La idea es modelar las páginas y sus comportamientos para lograr pruebas claras de escribir, entender y mantener.
Los fixtures son objetos JSON definidos en archivos individuales y que podemos usar en cualquier momento dentro de nuestros test asignándoles un alias. En nuestro caso los usaremos para alojar nuestros locators.
Un aspecto de mucho interés es sin lugar a duda el resultado de las pruebas automatizadas, más aún si el proyecto se encuentra en sus últimas etapas. Los reportes de pruebas automatizadas son muy importantes, ya que con ellos se puede obtener feedback en cualquiera momento sobre el estado actual de un proyecto y en cuestión de minutos, y de esta forma se optimiza el tiempo de las personas interesadas.
Volviendo unos pasos atrás, la estructura de nuestro framework de automatización en el artículo anterior quedó de la siguiente forma:
Creamos el folder llamado “cucumber” dentro del folder “integration” y en ese folder irán nuestros features y steps.
Luego dentro del folder “support”, creamos otro folder llamado “pages” donde irán nuestras páginas para poder realizar el patrón de diseño page object model.
Creamos un archivo feature dentro de la carpeta cucumber con el nombre “test”, en el van a ir todos nuestros Scenarios para ese Feature en lenguaje Gherkin.
Podemos observar en este caso 3 Scenarios distintos pero muy similares.
Creamos dentro de la carpeta “cucumber” otra carpeta con el mismo nombre del feature para que se pueda comunicar con los pasos.
En este caso la carpeta se llamará test y dentro de la carpeta crearemos el siguiente archivo testStep.spec.js
Aclarar que para que el archivo test.feature se pueda comunicar con el step, debe tener una carpeta llamada de igual forma que el feature (en este caso la carpeta se llama test).
En nuestro archivo testStep.spec.js vamos a crear nuestros pasos, pero primero debemos importar nuestros Given, When, Then, And
Esto sería para poder crear una función basada en nuestros features.
Creamos las funciones basadas en nuestro Scenarios, dentro de esa función colocaremos los pasos correspondientes.
Usaremos los siguientes comandos de Cypress
cy.visit(‘URL’) = “Nos permite cargar la URL”.
cy.get(‘elemento’) = “Selecciona uno o más elementos del DOM (html y css).
.click() = Hacer click sobre un elemento.
.should() = para las aserciones
Una aserción es lo que nos permite comprobar si nuestros tests pasaron o no.
Si no hemos definido ninguna aserción para nuestras pruebas, siempre pasará como valido y la prueba no servirá para nada
Cypress usa ChaiJS para definir aserciones
Para ejecutar nuestros 3 tests (Scenarios), vamos a usar las siguientes dos opciones.
1) Por medio de la interfaz grafica
2) Por medio de comandos en modo headless
Abrimos nuestro CMD y parados sobre la carpeta del proyecto ejecutamos el comando “npm run cypress:open” para abrir la interfaz gráfica que nos trae cypress.
Vamos a poder observar que del lado derecho esquina superior se pueden elegir distintos navegadores para ejecutar nuestras pruebas.
Para ejecutar nuestros test vamos hacer click donde dice test.feature
Automáticamente se abrirá el browser y se ejecutaran nuestras pruebas.
Nos dirigimos a nuestro CMD y parados sobre la carpeta del proyecto ejecutamos el comando “.\node_modules\.bin\cypress run”.
Esto logrará ejecutar nuestros test por consola por detrás en modo headless, sin abrir el browser.
Esta forma de ejecución nos va a permitir que se graben videos de todas las pruebas y que en caso de fallar alguna, tome una captura de pantalla.
En la carpeta “pages” que la creamos dentro dela carpeta “support” vamos a crear nuestras páginas.
Como podemos observar en nuestros tresScenarios tenemos elementos que pertenecen a 4 páginas (home, Stories, Servicios,Blog) y además agregaremos una para nuestras URL a navegar.
3 elementos a HOME
1 elemento a Stories
1 elemento a Servicios
1 elemento a Blog
En nuestra carpeta “fixtures” que ya trae Cypress por defecto, vamos a crear 5 fixtures.
Es acá donde vamos a usar estos archivos JSON para nuestros locators
Colocamos nuestros localizadores en sus respectivos archivos JSON
En este paso vamos a ir a la carpeta “pages” donde creamos los archivos js para cada página y en cada página crearemos métodos los cuales se comunicarán con nuestros archivos JSON que tienen nuestros locators.
Estos métodos nos servirán para que cumplan la función correspondiente como un click, escribir en un input, navegar a un sitio web, etc.
Dentro de cada método vamos a usar el comando cy.fixture() para levantar todos nuestros datos, en este caso los locators.
Una vez que levanto esos datos voy a usar un then() para pasarle el resultado de haber levantado ese JSON.
En la clase navigate (Un método para navegar a la URL)
En la clase homePage (Tres métodos, los cuales deberían hacer click)
En la clase storiesPage (Un método de validación del título)
En la clase blogPage (Un método de validación del título)
En la clase serviciosPage (Un método de validación del título)
Por último nos dirigimos a nuestro step, donde vamos a llamar a estos métodos, donde debemos primero importar la clase para así poder acceder a sus métodos.
Podemos observar, que vamos a poder usar estos métodos cuando los necesitemos, con solo importar la clase tendremos acceso a ellos. Lo mas importante es que vamos a poder eliminar código repetitivo y que sea más fácil de mantener
Vamos a integrar y ejecutar las pruebas de Cypress con la canalización de Azure DevOps de una forma muy simple.
Requisitos excluyentes:
a) Debemos tener nuestro framework de automatización en funcionamiento en nuestra máquina local.
b) Debemos tener el proyecto en la nube, en el repositorio remoto, en Azure DevOps (Importante, antes de subir nuestro framework a la nube, debemos generar un archivo .gitignore para colocar dentro la carpeta node_modules).
c) Nuestro framework debe generar un archivo Junit XML al final de la ejecución.
Vamos a descargar algunos paquetes npm por medio del comando “npm install cypress-mochawesome-reporter junit-report-merger mocha-junit-reporter cypress-multi-reporters mocha”
Abrimos el CMD, nos paramos sobre la carpeta y ejecutamos el comando.
mocha-junit-reporter = Genera un archivo XML de JUnit para cada especificación.
junit-report-merger = Como mocha junit reporter genera un archivo Junit XML para cada especificación, necesitamos fusionarlos todos al final de crear un solo archivo XML.
cypress-mochawesome-reporter = Este paquete ayuda a generar informes HTML.
cypress-multi-reporters = Este paquete se utiliza para configurar varios informes en nuestro caso Junit Reporter y HTML Reporter.
Vamos a configurar el archivo cypress.json y vamos a copiar y pegar el siguiente código.
Vamos a configurar el archivo index.js que se encuentra dentro de la carpeta plugins.
Copiamos y pegamos el siguiente código.
Vamos a ir al archivo index.js que se encuentra dentro de la carpeta support.
Copiamos y pegamos el siguiente código.
import 'cypress-mochawesome-reporter/register';
Por ultimo vamos a realizar dos pasos cortos, el primero ir a nuestro package.json y en script generar uno especificado para correr las pruebas en modo headless.
Y el segundo será ejecutar por consola las pruebas en modo headless, con el comando “npm run cypress:run” y verificar que nos generó los reportes.
Creamos una nueva canalización.
Vamos a Pipelines y le damos en el botón New pipeline
Click en usar editor clásico
Elegir el repositorio y proyecto correctos
Select a source: Azure Repos Git
Team Project: el nombre del proyecto
Repository: el nombre de su repositorio donde ha insertado el código
Rama predeterminada: main o la deseada
Y le damos click a continuar.
Seleccionamos la plantilla y elegimos la opción “trabajo vacío”.
Elegir las opciones de canalización.
Haga click en Pipeline, del lado izquierdo de la pantalla, y especificamos las opciones deseadas.
Click en Cypress desde el lado izquierdo y elegimos las opciones deseadas.
Click en (+) y agregamos la tarea de instalación.
Debemos buscar para instalar NPM o paquetes de instalación y lo agregamos.
Luego configuramos las tareas de paquetes de instalación.
Buscar y agregar “Command line” para ejecutar las pruebas de Cypress.
Luego vamos a configurar las tareas del Command line para ejecutar Cypress Test en Azure DevOps.
Agregar como tarea para el resultado de las pruebas “Publish Test Results”.
Configuramos la tarea.
Una vez que completamos todas las tareas hacemos click en guardar y poner en cola.
Podemos decir que el patrón de diseño Page Object Model junto a los archivos JSON de la carpeta fixture nos ayudan a modelar las páginas y sus comportamientos para lograr pruebas claras de escribir, entender y mantener.
Respecto a los reportes de resultados para nuestras pruebas, son muy importantes ya que nos brindan feedback sobre el estado actual del proyecto en cualquier momento, así se optimiza el tiempo de las personas interesadas.
La CI con Azure DevOps Pipelines o con cualquier otra herramienta nos agiliza el proceso de liberación de software, buscando responder rápidamente a las exigencias de los negocios. Es vital para acelerar todo el proceso de entrega, ya que permite, en forma temprana, encontrar y corregir fallas o realizar mejoras oportunamente antes de la salida a producción.
