Web SEO a prueba de fallos con Cypress

En el artículo de hoy hablaremos de las pruebas web, crearemos un ejemplo real con Cypress y veremos sus ventajas e inconvenientes.

¿Tienes un sitio web y nociones de programación? Esto mejorará la experiencia de tus visitantes, así que también repercutirá en mejorar tu SEO.

Introducción

Si programas o desarrollas código web, es habitual encontrar o generar errores.

Añades uno o varios elementos al sitio y que de repente (sobre todo cuando el proyecto va creciendo o si el código lo trabajan varias personas) todo falla. Esto provoca que puedas pasar horas y horas buscando un fallo tonto o que algo importante deje de funcionar.

Una parte muy importante del proceso de creación y edición web antes de la salida a producción, es la fase de pruebas. Antes de poner un proyecto en marcha o aplicar un cambio en el sitio real, debemos asegurarnos que todo funciona como debería.

La fase de pruebas

Cuando programamos existen varias técnicas para realizar pruebas de nuestro sitio web, la forma más "básica" consiste en hacer debugging añadiendo un console.log tras cada función para que nos vaya indicando si todo va bien, luego borramos ese código cuando publiquemos el sitio y lo probamos todo sobre la marcha.

Además de que no es lo más limpio, es más lento a largo plazo y no es nada profesional utilizar ese método.

Desventajas de console.log vs test e2e

Aunque todo desarrollador tanto de frontend como backend lo ha utilizado y lo utiliza alguna vez... usar console.log para probar código no debería ser lo normal porque aunque pueda parecer rápido es preferible perder 5 minutos y programar unos test que nos podrían ahorrar horas y frustraciones.

Test vs "a pelo"

¿Has oído alguna vez la expresión "Reinventar la rueda"? Si no usas test te enfrentas a esto. Pero para situarte, te voy a poner un caso real:

Tengo un sitio web con un formulario de contacto, hago todo el código y cuando lo tengo ya preparado, abro mi navegador web, entro al sitio y lo pruebo. ¡Vaya! Todo parece ir bien a la primera, soy un genio.

Pero como más vale prevenir que curar... vuelvo a abrir la web, relleno el formulario y lo envío otra vez por si acaso. ¡Madre mía! ¡¿Que pasa?! Pero si antes funcionaba y ahora le doy a enviar y no hace nada.

20 minutos y unos cuantos pelos arrancados más tarde.....

- Calma, calma, no he puesto el email en el formulario y como falta un campo no se envía, voy a preparar un mensaje de error para el usuario y si no pone email le saltará un aviso para que lo rellene.

Tras crear el código vuelvo a la web y lo pruebo. ¡Ahora sí! Cuando el usuario no pone el email le muestra un aviso y no le deja seguir. Ostras.. Pero tengo que probar que pasa si está todo bien y si una vez aparece el error puedo rellenar lo que me falta y seguir con el envío.

No quiero alargarme mucho más porque con esto creo que ya hemos ilustrado bien lo que pasa. Para algo tan sencillo como probar un formulario, he tenido que cargar el sitio varias veces, la primera vez perdí 20 minutos hasta darme cuenta de que el fallo era tan sencillo como que el usuario no rellenase el campo, después, y si no queremos sorpresas en el sitio final, probar los diferentes errores 1 a 1 tanto si fallan como si no...

Tipos de pruebas automatizadas

Para hacer nuestras comprobaciones como profesionales existen una serie de herramientas automatizadas que ponen a prueba nuestro sitio web y nos permiten asegurarnos de que todo funciona como debe con un mínimo esfuerzo.

• Test e2e: Son pruebas funcionales de toda una aplicación o sitio web en conjunto. Replican el comportamiento de los usuarios y tienen como propósito validar que todo funcione bien y como se espera.
• Test unitarios: Prueban de forma individual las funciones y/o métodos que usa nuestra aplicación o sitio web.
• Test de integración: Las pruebas de integración verifican que los diferentes módulos y/o servicios usados por nuestra aplicación funcionen en armonía cuando trabajan en conjunto.

En el artículo de hoy nos centraremos en las pruebas de tipo e2e (end to end) .

Como funcionan las pruebas e2e

Estas pruebas se realizan creando un itinerario como si fuese el propio usuario que navega por nuestro sitio y nos permiten probar todos los aspectos de nuestro sitio web.

Ventajas de las pruebas e2e

• Facilita la detección de errores o mal funcionamientos que pueden afectar a la integración de los componentes.
• Simplifica las pruebas web en varias resoluciones y/o dispositivos
• Prueba tu web y sus funciones como un visitante

Desventajas de las pruebas e2e

• Son pruebas lentas, sobre todo cuando la aplicación crece (la ejecución de los test se puede eternizar).
• Pueden ser complejas ya que tenemos que tener un entorno en funcionamiento para ejecutarlas porque necesitamos que nuestra aplicación/web, sus bases de datos y todo lo que utiliza esté funcionando para las pruebas.
• Son pruebas caras, ya que requieren de bastantes recursos para crear un entorno de servidor de pruebas, etc...

Que herramienta de pruebas e2e elegir

Cuando pruebas el frontend de tu web o aplicación necesitas una herramienta capaz de comportarse tal y como lo haría uno de tus visitantes y en este apartado es indiscutible que Cypress ha marcado un antes y un después.

Cypress es una herramienta de testing rápido, fácil y fiable capaz de hacer cualquier cosa que funcione en un navegador.

Muchas empresas como PayPal, Walt Disney Studios o DHL ya lo utilizan y lo que es más importante, se trata de un proyecto de código abierto.

• Es más rápido, ya que se ejecuta en memoria y no requiere de toda la preparación que tienen los navegadores gráficos.
• Se pueden hacer capturas de pantalla o vídeos durante las pruebas.
• No es necesario tener un navegador instalado.
• Detecta cambios en el código.
• Incluye Mocha, Chai y Sinon.js
• Documentación muy amplia incluso con ejemplos en el momento de instalarlo.
• Curva de aprendizaje muy baja hasta aprender a implementarlo.
• Las pruebas se pueden dividir en categorías y subcategorías.
• Código open source y comunidad activa que permite resolver dudas de forma rápida cuando nos estancamos.

Mi primer test con cypress

Si has leído todo lo anterior ya estás puesto en situación y sabes que lo necesitas, pero sí no, no pasa nada, no te juzgo. Aprenderás igual y te vendrá bien de todas formas.

Primero de todo instalaremos cypress, así que...

¿Qué necesito para instalar Cypress?

Puesto que Cypress es una aplicación de escritorio que se instala en tu equipo, necesitarás:

Sistemas operativos:

• macOS 10.9 o superior
• Linux: Ubuntu 12.04 y superiores, Fedora 21 y Debian 8
• Windows 7 o superiores

Node.js 12 o 14 o superiores

En cuanto a hardware ya que las pruebas se realizan sobre el equipo que las ejecuta, hacen falta al menos 2 CPUs para ejecutar Cypress + 1 CPU adicional si se quiere grabar vídeo + 1 CPU addicional por cada proceso que se ejecute fuera de Cypress (Frontend, backend, base de datos, kafka, ...), en cristiano... un procesador de al menos 4 núcleos. Vamos un PC de no más de 10 años... en cuanto a memoria necesitaremos un mínimo de 4GB y 8GB si se trata de pruebas más largas.

Además de esto si ejecutas Ubuntu o Debian necesitarás instalar estas dependencias:

apt-get install libgtk2.0-0 libgtk-3-0 libgbm-dev libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2 libxtst6 xauth xvfb

Y si usas CentOS necesitarás estas otras:

yum install -y xorg-x11-server-Xvfb gtk2-devel gtk3-devel libnotify-devel GConf2 nss libXScrnSaver alsa-lib

Instalando Cypress

Ahora que tenemos claro que nos hace falta, vamos a empezar a instalarlo, para ello tendremos que ir a la raíz de nuestro sitio web y ejecutamos lo siguiente:

npm install cypress --save-dev

Si no usas npm puedes hacerlo también con yarn

yarn add cypress --dev

Y si no sabes de que te hablo te recomiendo que te pases por mi otro artículo:

Tu primera aplicación web con Node.js || Omniscientia

Guía 100% en español sobre como crear tu primera aplicación con Node.js

OmniscientiaIvan Gil

¡Genial! Ahora ya deberías tener Cypress instalado en tu proyecto.

Abriendo Cypress por primera vez

Estás nervioso y entusiasmado, lo sé. Pronto todos tus proyectos tendrán controles de calidad y ahorrarás mucho tiempo.

Lo primero para utilizar cypress es encender Cypress, así que vamos a ello. Aunque existen varias formas, la que a mí más me gusta es abrir mi archivo package.json y añadirle estas sencillas líneas:

{
  "scripts": {
    "cypress:open": "cypress open"
  }
}

de esta forma nuestro proyecto sabe que cypress:open ejecuta cypress, así que una vez añadido esto en nuestro package.json solo faltará ejecutarlo:

npm run cypress:open

Ahora Cypress se abrirá y deberías ver algo similar a esto:

Elegiremos E2E ya que es de lo que trata el artículo pero Cypress está incorporando (aún en versión de pruebas) la prueba de componentes aislados.

Al ser la primera vez que ejecutamos Cypress nos configurará las pruebas iniciales de demostración y creará el archivo de configuración de la herramienta.

En la siguiente pantalla ya sólo nos faltará elegir nuestro navegador favorito para nuestras pruebas y podremos empezar.

Cuando le des a Start E2E testing por primera vez te da la opción de empezar con todo vacío o añadir test de muestra. Te recomiendo que crees los test de muestra ya que siempre estarás a tiempo de borrarlos, pero pueden ser una ayuda al principio.

El primer test  (CASO REAL)

Primero de todo vamos a crear nuestro archivo de test, estará situado en la carpeta cypress\e2e y su nombre será loquequieras.cy.js es importante que esté terminado en .cy.js ya que cypress reconocerá todos los archivos con esta terminación como test.

El primer test  - Prueba de artículo (CASO REAL)

Caso: Comprobaremos esta misma web localizando el primer artículo visible en la página de portada y accederemos a el. Una vez dentro verificaremos que se trata realmente de un artículo, comprobaremos que tiene contenido y para acabar de asegurarnos de que todo carga, comprobaremos el bloque de comentarios.

Dificultades: En esta prueba concreta nos encontraremos que cuando accedemos a la web los elementos no son visibles porque nos aparece una ventana emergente solicitando el permiso para utilizar las cookies. El otro problema al que nos enfrentaremos es que esta web en su pie de página conecta con una API para obtener las imágenes de nuestro Instagram, pero puesto que la prueba la haremos localmente, la URL no coincidirá con omniscientia.es y la API no querrá entregarnos los datos por lo que recibiremos un error desde el principio.

Procedimiento: Primero de todo crearemos un archivo llamado general.cy.js en nuestra carpeta cypress/e2e con las pruebas a realizar, después interceptaremos las peticiones hacia la API y crearemos el archivo con los datos de la API

Tal y como hemos dicho, creamos nuestro archivo general.cy.js y empezaremos de la siguiente forma:

context servirá para que cypress nos muestre el nombre de la prueba

beforeEach se ejecutará antes que cualquier test así que lo aprovechamos para interceptar todas las peticiones de tipo GET hacia lo que sea pero acabado en /instagram y cambiamos su respuesta por el contenido de nuestro archivo instagram.json, además de esto visitaremos la ruta raíz (localhost:5555 que es donde está el sitio de pruebas de nuestra web)

Es momento de crear nuestro instagram.json con los datos de muestra. Lo haremos dentro de la carpeta cypress/fixtures, lo único que haremos será poner los datos tal y como nos los devuelve la API, en nuestro caso es así:

Ahora que nuestro test cambia los datos reales de la API Instagram por los falsos en la carpeta fixtures de Cypress, ya podemos empezar con las pruebas:

En la imagen de arriba está la prueba escrita por completo, ¿como funciona? Lo vemos.

1- Cuando ejecutemos Cypress tendremos "Prueba general del sitio web" porque así lo hemos indicado en context.

2- Iniciaremos el test "Prueba de navegación hasta el artículo" porque lo hemos llamado así con describe

3- Cuando el test se vaya a iniciar, antes de nada Cypress cambiará las llamadas a la API real de instagram por unos datos falsos que hemos creado previamente y luego accederá en nuestra web.

4- Una vez en nuestra web se nos abrirá una ventana para pedirnos consentimiento de las famosas cookies. Gracias a que hemos indicado un beforeEach (antes de las pruebas), buscaremos el cuadro de cookies con id #cookies y haremos clic en el botón de aceptar.

5- El cuadro de cookies se ha cerrado así que ahora le pediremos a Cypress que busque un artículo y se posicione en su título, cuando lo haga le hemos indicado que haga clic.

6- Ahora y puesto que si nada a fallado deberíamos haber entrado en el artículo lanzamos el mensaje de "Puedo acceder a un artículo" y lo verificamos capturando el sitio web y comprobando que la página contenga la clase post-template (nuestra web inyecta esta class en el body html de todos los artículos)

7- Ahora que sabemos que estamos realmente en un artículo cogeremos el class .c-content y entraremos dentro del primer párrafo para pedirle a Cypress que nos confirme que realmente existe un párrafo de texto (el .c-content es el nombre que le damos nosotros en html al contenido de nuestros artículos, esto cambia de una web a otra por lo que debes cambiarlo por la class que tenga tu web)

cy.get('.c-content p').should('exist')

8- Ya por último sabemos que podemos entrar en la web, aceptar las cookies, navegar hasta un artículo, el artículo carga el contenido así que seleccionamos un bloque del pié de página como lo es el apartado de comentarios y verificamos que existe.

it('El submódulo de comentarios funciona' ()=> {
	cy.get('.article-comments').should('exist')
})

En realidad podemos iniciar sesión, probar a escribir un comentario, borrarlo y profundizar mucho más, al igual que podemos en el artículo llamar a la base de datos y no solo comprobar que hay un texto si no verificar que el texto que se muestra es realmente el del artículo. Pero como introducción a Cypress y por ahora pienso que si llegas hasta aquí vas a tener una buena noción y no está nada mal.

¡Nos vemos en el siguiente artículo!