QA

Cypress II: Patron de diseño POM, fixtures y CI con Azure DevOps Pipelines

Publicado por
Mauro Valls
Cypress II: Patron de diseño POM, fixtures y CI con Azure DevOps Pipelines
Escrito por
Mauro Valls
Publicado en
February 27, 2024
Tiempo de lectura
Categoría
QA

Primera parte click aquí

Introducción

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.

¿Qué es el patrón de diseño Page Object Model?

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.

¿Qué son los fixtures?

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.

¿Qué son los reportes?

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.

Llego la hora de lo divertido y vamos a continuar con nuestro framework de automatización que habíamos construido.

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.

integration

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.

pages

Lo que vamos a hacer ahora, es crear nuestros primeros Scenarios, Steps y ejecutarlos.

1

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.

Creacion archivo feature

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).

feature

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.

importar  Given, When, Then, And

Creamos las funciones basadas en nuestro Scenarios, dentro de esa función colocaremos los pasos correspondientes.

¿Como lo vamos hacer?

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

crear  aserción

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

Interfaz grafica

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.

interfaz

Vamos a poder observar que del lado derecho esquina superior se pueden elegir distintos navegadores para ejecutar nuestras pruebas.

interfaz 2

Para ejecutar nuestros test vamos hacer click donde dice test.feature

 test.feature

Automáticamente se abrirá el browser y se ejecutaran nuestras pruebas.

se abrirá el browser

Modo headless

         

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.

CMD

Imaginen tener 100 pruebas que tienen un elemento en común y a este le modificaron algún atributo. Sería una locura cambiar 100 veces este elemento. Por eso nuestro siguiente paso será optimizar nuestras pruebas por medio del patrón de diseño POM y nuestros fixtures.

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

carpeta page

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

localizadores

localizadores

localizadores

localizadores

localizadores

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)

 clase navigate

En la clase homePage (Tres métodos, los cuales deberían hacer click)

clase homePage

En la clase storiesPage (Un método de validación del título)

clase storiesPage

En la clase blogPage (Un método de validación del título)

clase blogPage

En la clase serviciosPage (Un método de validación del título)

 clase serviciosPage

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.

testStep

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

CI con Azure DevOps Pipelines

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.

¿Cómo generamos informes XML y HTML en Cypress?

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.

cypress.json

Vamos a configurar el archivo index.js que se encuentra dentro de la carpeta plugins.

Copiamos y pegamos el siguiente código.

archivo index.js

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';

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.

 package.json

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.

reports

modulos

Ahora si podemos usar este archivo XML cuando se integra con CI/CD, ya sea Jenkins, Azure DevOps o cualquier otra herramienta.

Creamos una nueva canalización.

Vamos a Pipelines y le damos en el botón New pipeline

new pipeline

Click en usar editor clásico

editor

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”.

trabajo vacío

Elegir las opciones de canalización.

Haga click en Pipeline, del lado izquierdo de la pantalla, y especificamos las opciones deseadas.

especificamos las opciones deseadas

Click en Cypress desde el lado izquierdo y elegimos las opciones deseadas.

Click en Cypress

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.

Click en (+)

 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.

Command line

configurar las tareas del Command line

Agregar como tarea para el resultado de las pruebas “Publish Test Results”.

Configuramos la tarea.

Publish Test Results

Configuramos la tarea.‍

Configuramos la tarea.‍

Una vez que completamos todas las tareas hacemos click en guardar y poner en cola.

 click en guardar y poner en cola

Conclusión

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.

attach icon
Adjuntar archivo
máximo: 10MB
Descarga el archivo haciendo click en el botón
Click aquí
¡Ups! Algo salió mal al enviar el formulario.

Crea tu propio manual de marca con esta plantilla gratuita.
¡Organiza tus activos de diseño de forma más eficiente!

Es
Eng