DEV Community

Fran López
Fran López

Posted on

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

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.

¿Y si hubiera una forma de que cada vez que fuéramos a hacer una Pull Request, automáticamente se levantará una máquina limpia, se ejecutarán los tests en ella y si todo va bien nos dejará mezclar la rama?

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;

GitHub Actions es una herramienta de automatización que permite definir flujos de trabajo personalizados en respuesta a eventos específicos dentro de un repositorio de GitHub.
Si hablamos de CI con GitHub Actions permite automatizar tareas esenciales como ejecutar pruebas de código, realizar compilaciones y verificar que el nuevo código cumple con los estándares de calidad, todo ello sin salir de GitHub.

GitHub Actions es flexible, fácil de configurar y permite crear flujos de trabajo personalizados con una amplia gama de posibilidades. Al estar integrado en GitHub, facilita la automatización sin necesidad de herramientas externas y así tener el ciclo de desarrollo en un solo lugar.

Puedes definir procesos automáticos que verifiquen y validen tu código cada vez que se realiza un cambio, lo que asegura un desarrollo más fluido y un producto final más robusto.

Paso 1: El ejemplo que vamos a usar

Como ya vimos en el primer post, Hola, Playwright (I) - Conceptos e2e y configuración inicial. Vamos a realizarlo sobre el proyecto Open Source Mongo Modeler.

Paso 2: Lanzando test sin interfaz de usuario

Vamos a configurar el package.json y añadir un script, al lanzar dicho script vamos a lanzar los test e2e sin 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"
  },
Enter fullscreen mode Exit fullscreen mode

En la terminal utilizamos dicho comando:

npm run ci:e2e
Enter fullscreen mode Exit fullscreen mode

Como podemos ver en la imagen, vemos el resultado de los test sin interfaz de usuario.

Imagen utilizando el comando y pasando los test e2e sin interfaz de ususario

Paso 3: Definiendo un workflow de Github Actions

Para automatizar el lanzamiento de los test e2e sin interfaz de usuario. Vamos a crear un workflow con Github Actions, para que en cada pull request lanze los test y si está todo ok poder aprobar dicha pull request.

En la raíz del proyecto está la carpeta .github en su interior la carpeta workflow y el archivo ci.yml donde vamos a definir el workflow de los test e2e.

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
Enter fullscreen mode Exit fullscreen mode

Esta sección garantiza que cualquier cambio en el código pase por pruebas exhaustivas que evalúan tanto el frontend como los flujos completos de la aplicación, proporcionando una capa extra de confianza antes de aprobar cambios en el repositorio.

Paso 4: Subiendo los cambios

Paso 5: Probando el proceso

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

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

Hola, Me llamo Fran y me gusta desarrollar Front End y trabajar como QA desarrollando pruebas de e2e.

Si quieres conectar conmigo, te dejo aquí mi perfil de Linked in:

Top comments (0)