DEV Community: Fran López

Hola, Playwright (II) - Integración CI con Github Actions.

Fran López — Mon, 25 Nov 2024 12:34:38 +0000

Introducción

En nuestro post anterior vimos como instalar Playwright, definir una prueba de end to end sencilla, y ejecutarla en un navegador local.

Esto está muy bien, podríamos pedirles a nuestros desarrolladores que antes de mezclar a main sus cambios, lanzaran estos tests e2e en sus máquinas y solo subieran los cambios si todo va bien, pero podríamos encontrarnos varios problemas:

Primero, que es muy normal que con las prisas a uno se le pase hacerlo y directamente suba los cambios (esto podríamos evitarlo utilizando herramientas como husky, más info en este post).
Segundo, si usáramos una tool como Husky que forzara al desarrollador a ejecutar los tests en cada push, estaríamos sobrecargando su máquina y haciendo más lento el proceso, cuando igual lo que queremos es que solo se ejecute en una pull request.
Tercero, puede que la máquina del desarrollador no sea el escenario ideal, igual está dentro de una VPN, o tiene acceso a la red... y no queremos que esto afecte a los tests.

¿Te imaginas un proceso en el que, cada vez que crees una Pull Request, automáticamente se inicie una máquina limpia, se ejecuten todos los tests en ella y, si todo sale bien, se permita fusionar la rama sin contratiempos?

Bienvenido al maravilloso mundo de los CI/CD, en este post vamos a ver cómo configurar un pipeline de CI/CD en Github Actions para ejecutar nuestros tests de Playwright en cada Pull Request.

TL;DR;

Partimos del primer post de esta serie (ya tenemos playwright instalado y configurado)

Para poder incluir los tests de e2e en nuestro flujo de integración continua, si usamos Github Actions, tenemos que:

Definir un comando en nuestro package.json que ejecute los tests de e2e sin levantar interfaz de usuario.

./package.json

  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives
 --max-warnings 0",
    "preview": "vite preview",
    "format": "prettier --write .",
    "test": "vitest",
    "prepare": "husky || \"No need to install husky\"",
    "tsc-check": "tsc --noEmit",
    "e2e": "playwright test --ui",
+   "ci:e2e": "playwright test"
  },

En nuestro flujo de Github Actions añadir una entrada para que los ejecute cuando se lance una Pull Request.

./.github/workflows/ci.yml

name: CI workflow

on: pull_request

jobs:
  e2e-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Use Node.js 18.13.0
       uses: actions/setup-node@v2
        with:
          node-version: '18.13.0'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build
       run: npm run build

      - name: Check TypeScript Types
        run: npm run tsc-check

      - name: Run E2E tests
        run: npm run ci:e2e

¿Quieres ver cómo funciona esto paso a paso? Sigue leyendo :).

Paso 1: El ejemplo que vamos a usar

Arrancamos del primer post de esta serie, donde instalábamos playwright, hacíamos el setup y escribíamos nuestro primer test de e2e.

Tomamos como punto de partida el primer post de esta serie.

El ejemplo que estamos utilizando como base es el proyecto Open Source Mongo Modeler.

Paso 2: Lanzando test sin interfaz de usuario

En el primer post de esta serie vimos como podemos lanzar los tests de e2e con una interfaz de usuario que nos permite ver en tiempo real cómo se ejecutan los tests, esto está muy bien en tiempo de desarrollo, ya que podemos ver si la interacción con la interfaz es la esperada y podemos incluso depurar e ir atrás y adelante en la línea del tiempo.

Cuando nuestros tests ya están listos, lo que queremos es que se puedan lanzar desde el terminal y nos devuelvan un resultado, abrir la interfaz de usuario en nuestra máquina local podría meter ruido, y... lo más importante, en una máquina virtual o contenedor de un servidor de integración continua no tenemos interfaz de usuario, son máquinas mínimas y tiramos de terminal.

¿Qué podemos hacer? Playwright nos permite lanzar los tests sin interfaz de usuario, para ello vamos a crearnos un comando adicional en nuestro package.json

package.json

  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives
 --max-warnings 0",
    "preview": "vite preview",
    "format": "prettier --write .",
    "test": "vitest",
    "prepare": "husky || \"No need to install husky\"",
    "tsc-check": "tsc --noEmit",
    "e2e": "playwright test --ui",
+   "ci:e2e": "playwright test"
  },

Si lo probamos en nuestro terminal con npm run ci:e2e veremos que se lanzan los tests sin interfaz de usuario.

npm run ci:e2e

Si lanzamos este comando, podemos ver que se lanzan los tests y no se abre ningún navegador.
Al lanzar este comando, vemos como sólo se informa de los resultados vía salida del terminal de texto asociado.

Ya estamos listos para integrar esto en nuestro flujo de integración continua.

Paso 3: Definiendo un workflow de Github Actions

Github actions funciona de una manera muy sencilla:

En la raíz de tu proyecto creas una carpeta .github y dentro otra worfklows, la ruta completa sería la siguiente: .github/workflows
Dentro de esa carpeta crearemos ficheros con extensión .yml que definirán los workflows que queremos que se ejecuten en nuestro proyecto.
Cuando hagamos push de las acciones, Github las detecta y está listo para ejecutarlas en el momento que le hayamos indicado (por ejemplo, cuando vayamos a hacer una Pull Request).

Lo de forzar a que ciertas carpetas tengan un nombre concreto es una convención de Github, si no lo haces así, no se ejecutarán los workflows, se llama configuración por convención o nomenclatura.

Ya sabemos dónde colocar nuestros workflows, ¿Definimos uno?

Seguimos la nomenclatura de yml y las entradas que nos permite Github Actions.
Creamos un archivo, por ejemplo, lo podemos llamar ci.yml y lo colocamos en la carpeta .github/workflows
En ese archivo le damos un nombre.
Después le decimos cuándo se va a lanzar el flujo, en este caso queremos que se lance cuando se haga una pull request.

Como va quedando:

./.github/workflows/ci.yml

name: CI workflow

on: pull_request

Cuidado con las tabulaciones, en yml es importante.

Ahora vamos a definir los jobs que se van a ejecutar, en este caso vamos a lanzar los tests de e2e.

Más información sobre como funcionan las Github Actions en este post.

En este caso, le podemos decir que lance el job de e2e

./.github/workflows/ci.yml

name: CI workflow

on: pull_request

+  e2e-tests:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v2

+      - name: Use Node.js 18.13.0
+       uses: actions/setup-node@v2
+        with:
+          node-version: '18.13.0'
+          cache: 'npm'

+      - name: Install dependencies
+        run: npm ci

+      - name: Build
+       run: npm run build

+      - name: Check TypeScript Types
+        run: npm run tsc-check

+      - name: Run E2E tests
+        run: npm run ci:e2e

Que le estamos diciendo aquí:

Tenemos un job llamado e2e-tests.
Se va a ejecutar en una máquina con sistema operativo ubuntu.
Después vamos a traernos el código de nuestro repositorio.
Le decimos que usé la versión de Node.js 18.13.0 (lo añade a la máquina que ejecuta el job).
Instalamos las dependencias, fíjate que aquí usamos npm ci en vez de npm install. Esto lo hacemos para que no modifique el fichero package-lock.json.
Para asegurarnos que está todo bien construido, lanzamos el comando npm run build.
También lanzamos un chequeo de los tipos de TypeScript con npm run tsc-check.
Por último, lanzamos los tests de e2e con npm run ci:e2e.

Ya está todo listo para que, cuando hagamos commit y push de este archivo, Github Actions detecte que hay un nuevo workflow y lo ejecute cuando se haga una Pull Request.

A tener en cuenta: en el ejemplo de MongoModeler, el flujo de ci ejecuta dos jobs uno para comprobar que todo está ok y lanzar las pruebas unitarias, y otro para lanzar las e2e, como queda el flujo total:

./.github/workflows/ci.yml

name: CI workflow

on: pull_request

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Use Node.js 18.13.0
        uses: actions/setup-node@v2
        with:
          node-version: '18.13.0'
          cache: 'npm'

      - name: Install front
        run: npm install

      - name: Build
        run: npm run tsc-check

      - name: Tests front
        run: npm test

  e2e-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2

      - name: Use Node.js 18.13.0
       uses: actions/setup-node@v2
        with:
          node-version: '18.13.0'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build

      - name: Check TypeScript Types
        run: npm run tsc-check

      - name: Run E2E tests
        run: npm run ci:e2e

Paso 4: Subiendo los cambios

Ahora lo tenemos todo listo, Abrimos una pull request y hacemos commit y push. Nos llevaríamos los cambios a la rama main.

Paso 5: Probando el proceso

Cuando hacemos PR se lanza los jobs que hemos definido anteriormente, vemos como pasan correctamente. Con lo cual le estamos dando robustez a nuestro proyecto. Además, podemos ver detalles de la ejecución del mismo e incluso el terminal de como va el proceso.

Pincha en datails.

Paso 6: Settings y forzar a que pasen para poder hacer merge

Una funcionalidad interesante que nos ofrece Github es que poder impedir que alguien haga merge si no pasan los e2e test (con la opción de añadir excepciones para por ejemplo perfiles administradores). Para ello, entramos en nuestro portal de Github y nos vamos a los settings del repositorio y elegimos del panel izquierdo Rules / Rules Sets.

Pincha en "New ruleset"

Se nos abre un formulario, le damos un nombre a esa regla, le podemos llamar: pass-tests-before-merge y le decimos que la regla está activa.

Después tenemos la opción, por ejemplo un admin se pueda saltar esa regla si queremos.

Ojo con este bypass, sólo es útil para usuarios en concreto y casos puntuales justificados.

Lo siguiente es elegir a qué ramas va a aplicar, en nuestro caso la rama default se llama dev y la main es la que va a producción, así que pedimos que se apliquen en esas dos.

Y en el apartado de Rules marcamos Require Status check to pass:
Está bien marcar el primer check(Requires branches to up to data before merging), así nos aseguramos que la rama que tenemos tiene la última versión de dev o main.

Y para los checks, pinchamos en + Add Checks y buscamos el nombre del flujo de github que tenemos definido en nuestra carpeta de workflows (la que está bajo .github/workflows)

Ahí vemos que sale vació, pero si tecleamos ci (como se llama nuestro flujo), aparece y podemos seleccionarlo.

Se nos tiene que quedar algo así como:

Para finalizar pulsamos en el botón de create que hay al final del formulario.

Repositorio de ejemplo

Te dejo un enlace al proyecto de github con la configuración completa:

Enlace al repositorio con el proyecto y su configuración completa

Conclusión y siguientes pasos

Ya tienes todo listo para que tus tests e2e con Playwright corran como parte de tu proceso de CI/CD en GitHub Actions. Esto es oro puro para asegurarte de que todo esté bajo control antes de llevar cambios a producción. Ideal para esas aplicaciones que van creciendo y donde cada bug que arreglas tiene el potencial de invitar a un par más a la fiesta 😉. Menos sorpresas, más confianza.

En el próximo post de esta serie, daremos un paso más y aprenderemos cómo escribir tests e2e que interactúan directamente con APIs de servidor. ¡Prepárate para llevar tus pruebas al siguiente nivel! 🚀

Sobre mí

Hola, me llamo Fran y soy desarrollador Front End + QA, si quieres conectar conmigo, te dejo aquí mi perfil de Linked in, ¡encantado de conectar!

Hola, Playwright (I) - Conceptos e2e y configuración inicial.

Fran López — Wed, 30 Oct 2024 12:50:30 +0000

Introducción

Si hablamos de Unit Testing seguramente te resulte familiar, ... Es lo que vamos haciendo para generar piezas robustas de código, ... Eso sí, piezas por separado, ¿Qué pasa cuando las juntamos?... pues que pueden surgir problemas, aquí podemos seguir avanzando y hablar de pruebas de integración, pero... ¿Y si pudiéramos ir un paso más allá? ¿Por qué no automatizar pruebas manuales con la aplicación real funcionando? Bienvenido al lado oscuro de QA 🤗.

Las pruebas de extremo a extremo (E2E) nos permiten probar aplicaciones web en tiempo real de forma automática, simulando la interacción de un usuario con la aplicación, es decir, es como si una persona estuviera interactuando con la aplicación y comprobando visualmente que obtiene el resultado esperado.

Lo potente de esta aproximación es que puedes lanzar las pruebas cuando quieras y sin tener un humano detrás para comprobar manualmente que todo ha salido como esperabas.

Una herramienta muy potente para realizar este tipo de pruebas es PlayWright (Microsoft). En este post vamos a ver cómo podemos configurar PlayWright en nuestro proyecto de Front para crear y ejecutar pruebas E2E automatizadas.

TL;DR;

PlayWright es una herramienta de automatización de pruebas de extremo a extremo que permite escribir pruebas en JavaScript, TypeScript y Python. Se basa en que tú interactúas mediante código con el navegador, como lo haría un usuario real (haciendo clic, escribiendo texto, etc.) y después podemos comprobar los resultados de la interacción leyendo el DOM.

Playwright es una herramienta de pruebas de caja blanca. No conoce los detalles de tu código, esto nos permite probar cualquier aplicación web, independientemente de la tecnología que utilices.

Para usar Playwright:

Necesitas instalarlo en tu proyecto.
Configurarlo correctamente.
Definir tus pruebas.
Lanzarlas y esperar resultados.

¿Con ganas de entrar en detalle? Sigue leyendo...

Paso 1: Entendiendo PlayWright y e2e testing

Cuando desarrollamos unit tests, estamos probando piezas separadas, o si me aprietas, podemos probar a hacer test de integración y probar un conjunto de ellas, pero... Esto no es suficiente, cuando desplegamos una aplicación, debemos de tener alguna garantía de que el usuario pueda completar flujos de principio a fin. Siempre puede haber fallos tontos que no sean fáciles de detectar con tests unitarios o de integración.

¿Qué se hacía en muchos casos? Tener a testers manuales, es decir, personas que se hacían un guion con pasos e iban manualmente probando la aplicación, es decir:

Arrancas la aplicación en un entorno de QA (test), preproducción, o incluso producción (se puede plantear ejecutar tests de end to end en producción).
Tienes un guion con unos pasos.
Prueba a hacer los pasos y vas anotando y comprobando que todo funciona como esperas.

Esto de primeras puede parecer algo asumible, pero a poco que tu proyecto avanza te encuentras que:

El proyecto crece y cada vez tiene más funcionalidad, y lo que es peor, introducir una nueva característica puede romper una anterior.
Hacer un test manual de una característica puede ser viable la primera vez, pero cuando quieres salir a producción, lo suyo es, poder testearlo todo. Imagínate si la aplicación crece cuanto pueden tardar en ejecutar manualmente todos los tests.
Y si hablamos que tenemos que ser ágiles y poder desplegar a producción varias veces al día, no puedes estar esperando a que un tester manual pruebe todo.

¿Y si pudiéramos pasar esos test manuales a código? Es decir, que un bot simulará que pinchas en un botón, que tecleas en un input y después comprobará que el resultado es el esperado. Un ejemplo simple:

Un bot pincha en el input de usuario y teclea el email de una cuenta.
El mismo bot pincha en el input de contraseña y teclea la contraseña.
Y ahora busca el botón de login y pincha en él.
Por último, comprueba que ha entrado en la aplicación y que el usuario está logueado (ha navegado a la página principal y en la cabecera de arriba a la derecha aparece el nombre del usuario).

Esto es lo que se conoce como End to End Testing o e2e Testing.

La primera vez, crear ese script automático nos va a costar más que ejecutar un test de forma manual, pero a la larga, nos va a permitir:

Poder ejecutar esos tests de forma automática.
Poder ejecutar esos tests de forma automática en cualquier entorno (QA, preproducción, producción), así como en diferentes navegadores.
Poder ejecutar esos tests de forma automática en cualquier momento.

Paso 2: Instalando la herramienta

Como hemos comentado vamos a utilizar PlayWright para definir y lanzar pruebas e2e, es decir vamos a realizar pruebas en modo "caja negra": yo no sé en qué lenguaje o que detalles de implementación tiene tu solución, lo que voy a hacer es interactuar en el navegador con tu aplicación y comprobar que todo funciona correctamente ¿Cómo? Como si fuera un usuario real, es decir, voy a hacer clic en botones, rellenar formularios, comprobar que se muestran los datos esperados, etc.

Así que, ¿Cómo se instala PlayWright? Aquí viene la parte buena: la instalación de Playwright es sencilla y se realiza a través de npm o yarn, como cualquier otro proyecto Node.js. Así, evitamos instalaciones complejas con múltiples pasos y asistentes. Tienes dos opciones para organizar el proyecto de pruebas:

Crear el proyecto de E2E dentro del repositorio principal de frontend Puedes crear una subcarpeta dentro de tu proyecto frontend para centralizar las pruebas E2E. Una estructura típica sería:

  /proyecto
    /frontend
      /e2e

Crear un proyecto de pruebas como repositorio independiente (algo común en equipos de QA especializados), pero en este caso tendrías que tener en cuenta que tendrías que tener una forma de comunicar el proyecto de e2e con el proyecto de front end, es importante considerar cómo se comunicará con el proyecto frontend. Una práctica recomendada es utilizar una variable de entorno o un archivo de configuración que permita enlazar ambos proyectos de manera sencilla, o bien que el equipo de QA trabaje directamente sobre una versión desplegada en un entorno concreto, al que normalmente se le llama entorno de QA o entorno de testing. Esto último facilita que las pruebas se ejecuten sobre una versión estable de la aplicación sin interferir con el desarrollo en curso.

Nos ponemos manos a la obra, ya tenemos nuestra carpeta vacía esperando a que inicialicemos nuestro proyecto de pruebas. Para ello, abrimos un terminal y ejecutamos el siguiente comando desde la terminal de bash o ms-dos:

Si somos de npm:

npm init playwright@latest

Si somos de yarn:

yarn create playwright

Esto va a realizar una serie de pasos por nosotros:

Configura el proyecto de Playwright: Crea una estructura básica de archivos para las pruebas, con carpetas y archivos de ejemplo que te ayudarán a comenzar.
Descarga automáticamente los navegadores: Al ejecutar el comando, Playwright también descarga versiones específicas de los navegadores (Chromium, Firefox y WebKit) que necesita para ejecutar las pruebas. Esto asegura que las pruebas se realicen de manera consistente en los entornos adecuados.
Incluye archivos de configuración: Crea archivos de configuración iniciales (playwright.config.js) para personalizar y ejecutar las pruebas.

Cuando le damos a enter, la herramienta nos hará una serie de preguntas:

√ Where to put your end-to-end tests? · e2e

¿ En que carpeta vamos a crear tus tests? Lo normal es poner e2e o tests, pero puedes poner el nombre que quieras.

Add a GitHub Actions workflow? (y/N) · false

Uno de los puntos fuertes del e2e testing automático es que puedes incluirlo en tu ciclo de CI/CD (integración continua y despliegue continuo). ¿Esto qué es? Pues, que por ejemplo, cuando vayas a subir código a tu repositorio o quieras mezclar a tu rama principal.
Automáticamente, se ejecuta la batería de pruebas e2e y, si todo está correcto, se permite mezclar la rama o subir a producción.

En este paso de creación vamos a decirle que no. En otro post de esta serie os comentaremos cómo configurarlo de forma manual y así poder tener un control más fino.

√ Install Playwright browsers (can be done manually via 'npx playwright install')? (Y/n)

Por último, nos pregunta si queremos instalar los navegadores necesarios para ejecutar las pruebas. Es recomendable aceptar (opción "Y") en este momento, ya que, si decidimos no instalarlos ahora, tendremos que hacerlo manualmente más adelante usando el comando npx playwright install.

¿Y por qué tengo que instalar navegadores si ya los tengo en mi máquina?

Playwright instala versiones específicas de cada navegador (Chromium, Firefox, y WebKit) que han sido verificadas para funcionar de manera consistente con su entorno de pruebas. Esto asegura que las pruebas sean estables y predecibles, independientemente de las versiones que tengas instaladas localmente o de las actualizaciones que reciban esos navegadores en el futuro, además estas versiones personalizadas de los navegadores permiten evitar posibles inconsistencias entre máquinas de desarrollo o en entornos CI/CD, asegurando que las pruebas se comporten igual en cualquier entorno en el que se ejecuten.

Una vez ejecutado este wizard, nos ha tenido que quedar una estructura de carpetas parecida a lo siguiente:

  /Mongo-Modeler
    /e2e
    /src
    /playwright.config.js
    /package.json

paso 3: Configurando PlayWright

Ya tenemos nuestro proyecto e2e inicializado y PlayWright, nos queda:

Configurarlo para que sepa contra qué sitio web van a correr las pruebas.
Definir una prueba e2e.

Ahora toca configurarlo para poder ejecutar las pruebas de nuestro proyecto.

Vamos a realizarlo sobre el proyecto Open Source Mongo Modeler.

En este caso, hemos decidido ejecutar los e2e test directamente desde el entorno de desarrollo, por lo que tenemos que indicarle a playwright:

Cómo levantar ese servidor de desarrollo (en el caso de Mongo Modeler se arranca con el comando npm run dev).
Contra que URL va a correr las pruebas (en el caso de Mongo Modeler la aplicación corre en local en localhost:5173).

Está opción es buena para poder probar los e2e tests en local, e incluirlo en tu ciclo de integración continua, también hay equipos de QA que prefieren tenerlo todo en un entorno de servidor y simular que estamos tirando contra entorno real.

playwright.config.ts

+ const BASE_URL = 'http://localhost:5173/';

  export default defineConfig({
    testDir: './E2E',
    fullyParallel: true,
    forbidOnly: !!process.env.CI,
    retries: process.env.CI ? 2 : 0,
    workers: process.env.CI ? 1 : undefined,
    reporter: 'html',
    use: {
   /* Base URL to use in actions like `await page.goto('/')`. */
+     baseURL: BASE_URL,
      trace: 'on-first-retry',
    },
  webServer: {
+   command: 'npm run dev',
+   url: BASE_URL,
-   url: 'http://127.0.0.1:3000',
    reuseExistingServer: !process.env.CI,
   },

Y ahora en el package.json añadimos el comando para ejecutar los tests e2e:

  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "lint": "eslint . --ext ts,tsx --report-unused-disable-directives
 --max-warnings 0",
    "preview": "vite preview",
    "format": "prettier --write .",
    "test": "vitest",
    "prepare": "husky || \"No need to install husky\"",
    "tsc-check": "tsc --noEmit",
+    "e2e": "playwright test --ui"
  },

Aquí le indicamos que levante playwright y que use la interfaz de usuario, en artículos siguientes veremos otra opción para ejecutar los tests sin interfaz de usuario, esto es muy útil cuando queremos integrarlo en un entorno de integración continua, o si queremos añadirlo como un paso previo a un commit o push.

Ya estamos listos para crear nuestro primer test e2e y ejecutarlo, vamos a por el siguiente paso.

paso 4: Creo mi primer test e2e

Si lanzamos ahora los tests e2e, fallarían, porque no hay ningún test definido, vamos a crear uno simple.

Cuando arrancamos la aplicación, se muestra una ventana de landing en la que hay un botón que dice "Launch MongoDB Designer", cuando pulsamos ese botón, nos redirige a la página que contiene el editor.

¿Qué vamos a probar?

Navegamos a la raíz del proyecto.
Pulsamos en el botón "Launch MongoDB Designer".
Comprobamos que, en efecto, navega a la ruta "/editor.html".

Esta sería la página de landing

Esta sería la página del editor

El comportamiento esperado:

Para definir este caso:

Debajo de la carpeta e2e.
Creamos el fichero launch-mongodb-designer-link.spec.ts (spec viene de specification, también podremos usar test).

Ya que tenemos el fichero, le añadimos el siguiente contenido

./e2e/launch-mongodb-designer-link.spec.ts

import { test, expect } from '@playwright/test';

test('navigates to and verifies MongoDB Designer URL', async ({ page }) => {
  await page.goto('');

  await page.getByRole('link', { name: 'Launch MongoDB Designer' }).click();
  await expect(page).toHaveURL('http://localhost:5173/editor.html');
});

¿Qué estamos haciendo aquí?

Definimos un test y le indicamos con una descripción en texto que cubre.
Indicamos que es un test asíncrono (tenemos que esperar a que se resuelvan acciones).
Le indicamos que vaya a la raíz de la aplicación.
Buscamos el enlace que tiene el texto "Launch MongoDB Designer" y hacemos clic (se puede buscar un elemento por muchos criterios, en este caso lo hacemos por el rol y el nombre, también se pueden buscar por id, ...).
Una vez encontrado ese botón, simulamos un clic del usuario.
Una vez que se ha hecho clic, comprobamos que la navegación se ha realizado, y que en el navegador está en la URL esperada.

Ya que tenemos el test, solo tenemos que ejecutar desde la línea de comandos npm run e2e.

npm run e2e

Al lanzar esto desde el terminal, podemos ver que se abre la UI de playwright.

Ahora podemos darle al botón play o la tecla F5 del teclado y lanza todos los test. Como podemos ver tiene el Check de éxito.

En este caso MongoModeler es una aplicación pura de Front, ¿Qué pasaría si tuviera que interactuar con una API Rest o similar? Aquí tengo varias estrategias:

Puedo definir mocks para respuestas específicas de la API.
Puedo definir un servidor de Mock que tenga los mismos contratos que la API real.
También puedo tirar contra entorno real o QA

Todo esto lo veremos en los siguientes posts de esta serie.

Repositorio de ejemplo

Te dejo un enlace al proyecto de github con la configuración completa:

Enlace al repositorio con el proyecto y su configuración completa

Conclusión y siguientes pasos

Al arrancar un proyecto, todo puede parecer muy sencillo, desarrollas un par de ventanas, tienes tus pruebas unitarias, manualmente haces un par de comprobaciones y ya estamos listos, pero a poco que el proyecto crece, estos checks van tomando más tiempos y lo que es peor, metiendo un cambio puedes romper accidentalmente otras cosas.

Es por eso que es importante contar con pruebas automatizadas, y en este caso, con pruebas E2E. Con Playwright, puedes automatizar estas pruebas de extremo a extremo de manera sencilla y eficiente, y asegurarte de que tu aplicación funcione correctamente en cada actualización.

En el siguiente post de esta serie vamos a ver cómo integrar Playwright en un proceso de CI/CD pudiendo lanzar estas pruebas cada vez que vayas a levantar una Pull request.

Sobre mí

Hola, me llamo Fran y soy desarrollador Front End + QA, si quieres conectar conmigo, te dejo aquí mi perfil de Linked in, ¡encantado de conectar!

Configuración de Husky, lint-staged y Prettier para formatear en precommit.

Fran López — Fri, 12 Jul 2024 09:56:48 +0000

Introducción

¿Alguna vez has experimentado que, a pesar de haber acordado usar Prettier en tu equipo, un nuevo integrante no tiene el plugin instalado y sube código sin formatear correctamente?

¿Existe alguna forma de asegurarnos de que cualquier código que subimos a nuestro repositorio de Git cumpla con ciertos estándares mínimos?

TL;DR;

Para configurar Husky, lint-staged y Prettier para formatear el código en pre-commit.

Instala las herramientas necesarias: Instala Husky para manejar los hooks de Git, lint-staged para procesar solo los archivos modificados, y Prettier para el formateo del código.
Configura Husky: Inicializa Husky en tu proyecto y agrega un hook de pre-commit que ejecute lint-staged. Esto asegura que ciertos comandos se ejecuten automáticamente antes de cada commit.
Configura lint-staged: Especifica en lint-staged que Prettier debe ejecutarse en los archivos que coincidan con las extensiones de tu proyecto. Esto asegura que solo los archivos modificados y añadidos al área de staging sean procesados por Prettier.
Configura Prettier: Define las reglas de formateo que deseas usar en tu proyecto mediante un archivo de configuración de Prettier.

¿Quieres saber más en detalle? Sigue leyendo...

Husky se basa en los git hooks, scripts que se ejecutan antes o después de determinados comandos de Git.
Por ejemplo, cuando hacemos un commit, podemos tener el hook pre-commit que se ejecutará antes de realizar el commit. De esta manera, podemos configurar Husky para que ejecute herramientas como Prettier, incluso una batería de tests. Si todo va bien, el commit se realizará; de lo contrario, se producirá un error y el commit no se llevará a cabo. Esto nos asegura que el código en el repositorio esté siempre formateado según las reglas establecidas por Prettier.

Sin embargo, ejecutar estas herramientas en todos los archivos del proyecto cada vez que hacemos un commit podría ser ineficiente, especialmente en proyectos grandes, ya que demoraría el proceso. Aquí es donde entra en juego lint-staged. Con lint-staged, solo se procesan los archivos que han sido modificados y añadidos al staging del repositorio. Esto reduce significativamente el número de archivos que necesitan ser revisados, haciendo que el proceso sea más rápido y eficiente.

Paso 1: Instalación de dependencias

Asegúrate de que tienes Node.js y npm (o yarn) instalados en tu proyecto. A continuación, instala Husky, lint-staged y prettier, mediante npm o yarn.

Teclea esto en la terminal de bash o ms-dos.

npm:

npm install husky prettier lint-staged --save-dev

yarn:

yarn add husky prettier lint-staged --dev

paso 2: Configurar .prettierrc .prettierignore

Crea un archivo .prettierrc.json en la raíz de tu proyecto y añade tus reglas.
Ejemplo:

.prettierrc.json

+ {
+   "printWidth": 80,
+   "singleQuote": true,
+   "useTabs": false,
+   "tabWidth": 2,
+   "semi": true,
+   "bracketSpacing": true,
+   "trailingComma": "es5",
+   "arrowParens": "avoid",
+   "endOfLine": "lf"
+ }

Crea otro archivo .prettierignore en la raíz de tu proyecto. Es para que prettier no mire en esos ficheros.
- Ejemplo:

.prettierignore

+ {
+   node_modules
+   dist
+ }

Paso 3: Configurar husky y el pre-commit

Añade un hook pre-commit que se ejecutará antes de cada commit. Para pasar prettier y formatear el código.

El comando init simplifica la configuración de husky en un proyecto. Crea un script pre-commit en .husky/ y actualiza el script prepare en package.json. Las modificaciones se pueden hacer más tarde para adaptarse a su flujo de trabajo.

Teclea esto en la terminal de bash o ms-dos.

 npx husky init

Añade una configuración para lint-staged en package.json:

package.json

+ "lint-staged": {
+    "*.{ts,tsx}": [
+      "prettier --write"
+    ],
+    "*.css": [
+      "prettier --write"
+    ]
+  }

En la raíz tenemos la carpeta .husky, dentro de ella un fichero llamado pre-commit, añadimos lo siguiente.

./.husky/pre-commit

+ #!/usr/bin/env sh
+ . "$(dirname -- "$0")/_/husky.sh"

- npm test
+ npx lint-staged

paso 4: Prueba la configuración

Introduce cambios en un archivo .ts,tsx o css (mal formateados) y podrá ver como se lanza el precommit formatea automáticamente los ficheros.

Repositorio de ejemplo

Te dejo un enlace a un proyecto de github vacío con la configuración completada:

Enlace al repositorio con el proyecto vacío con la configuración completada

Conclusión

Cuando trabajas en equipo (incluso tú solo), es muy importante tener una base de código que sea homogénea y garantizar que cumpla unos mínimos, si no hay mucho riesgo de que el proyecto se te vaya de madre y no tengas manera de controlarlo.
Husky te permite integrar ganchos de git de una manera muy sencilla, en nuestro caso con lint-staged lo hemos configurado de forma que formatee automáticamente los archivos que se van a subir al repositorio, y con prettier nos aseguramos de que el código cumpla con un estándar de formateo consistente, ya te puedes olvidar de ir persiguiendo a tus compañeros para que instalen el plugin y lo configuren correctamente.
Si te animas, puedes añadir más herramientas a tu flujo de trabajo, como ESLint para detectar errores y problemas de estilo en tu código, o Jest para ejecutar pruebas unitarias. ¿Hasta dónde llegar? Aquí depende del equipo con el que estés trabajando y las necesidades que tengas. Si nunca has usado estas herramientas, te recomiendo que empieces poco a poco, y que tu equipo vaya madurando.

Sobre mí

Hola, me llamo Fran y soy desarrollador Front End + QA, si quieres conectar conmigo, te dejo aquí mi perfil de Linked in, ¡encantado de conectar!