Qunit automático con Github actions

Hace un tiempo publique una entrada donde explicaba como configurar Qunit para hacer nuestros unitarios de manera automática. En esa ocasión podíamos lanzar los test de manera automatizada y sin navegador pero solo en local.

En esta entrada aprenderemos a automatizar los test para que se lancen al realizar un pull request en Github y así poder determinar de manera rápida si el pull request es valido o no.

Antes de empezar, si no sabéis de que va esto de QUnit os recomiendo la serie de testing del blog para que tengáis un poco de contexto ya que en esta entrada utilizaremos solo el template.

Y ahora que ya tenemos el contexto, lo que vamos a hacer en esta entrada será la configuración de Github actions para ejecutar QUnit de manera automática después de un pull request y añadir en format de TAG y comentario el resultado en el pull request.

Empezando con la application UI5 (template BAS)

Pues como en muchas otras entradas, empezaremos con los elementos básicos.

  • Un repositorio Git en Github para alojar nuestra aplicación
  • Una aplicación en BAS des del template con la opción de deploy activada (aunque esto no es 100% necesario)
  • Nuestra nueva aplicación sincronizada en la rama master -> main con Github

Una vez tengamos el proyecto creado lo podemos sincronizar con GIT, si no sabemos como, en esta entrada te explico como, DevOps serie CI/CD en SAP BTP (Parte 3)

Este será el resultado después de estas primeras preparaciones:

  • Este es el resultado en Github:
  • Y esta es la estructura en nuestro BAS, nada nuevo ya que simplemente es la aplicación con el template

Preparando la configuración en BAS

Añadiendo las librerías

La manera mas rápida de añadir las librerías es con el comando “npm instal”. Añadiremos todas las librerías necesarias para invocar QUnit. Este es el listado completo

npm install karma karma-chrome-launcher karma-cli karma-coverage karma-ui5 puppeteer rimraf

Este sera el resultado en nuestro fichero package.json:

Añadiendo los ficheros de configuración de Karma

El siguiente punto ya lo vimos en la serie de testing que os mencione al inicio de esta entrada. Pero volvamos a ver como configurarlo. Para ello deberemos crear 2 ficheros que contienen las configuraciones de ejecución de pruebas y navegador por defecto.

En la raíz del proyecto creamos un fichero llamado “karma-ci.conf.js“. Este fichero tendrá la configuración básica con los tipos de test a ejecutar y el navegador a utilizar. Vamos a ver un poco el detalle y luego el código:

  • require(“./karma.conf”): Esta instrucción nos indica el fichero donde esta la configuración del framework y del navegador
  • Reporters: Tipo de pruebas, “progress” nos indica que se realizaran las pruebas de la carpeta Test, “coverage” si lo añadimos nos indicara que ficheros de nuestra aplicación testeamos y con que cobertura.
  • Browsers: Tipo de navegador y características que utilizaremos.

Este sera el fichero resultante:

module.exports = function(config) {
	"use strict";

	require("./karma.conf")(config);
	config.set({

		preprocessors: {
			"{webapp,webapp/!(test)}/*.js": ["coverage"]
		},

		coverageReporter: {
			includeAllSources: true,
			reporters: [
				{
					type: "html",
					dir: "coverage"
				},
				{
					type: "text"
				}
			],
			check: {
				each: {
					statements: 100,
					branches: 100,
					functions: 100,
					lines: 100
				}
			}
		},

		reporters: ["progress"],

		browsers: ["CustomChromeHeadless"],

		singleRun: true

	});
};

El siguiente fichero que añadiremos, como os podéis imaginar es el “karma.conf”, tambien en la raiz del proyecto.

Este será su contenido, como veis tenemos la configuración del framework donde también esta la referencia al fichero ui5.yaml que a su vez tiene la configuración para la aplicación (todo un entramado de ficheros de configuración la final)

module.exports = function (config) {
    "use strict";

    var chromeFlags = [
		"--window-size=1280,1024"
	];

    config.set({
        frameworks: ["ui5"],
        ui5: {
            type: "application",
            configPath: "ui5.yaml",
            paths: {
                webapp: "webapp",
            },
        },
        browsers: ["ChromeHeadless"],
        browserConsoleLogOptions: {
            level: "error",
        },
        customLaunchers: {
			CustomChrome: {
				base: "Chrome",
				flags: chromeFlags
			},
			CustomChromeHeadless: {
				base: "ChromeHeadless",
				flags: chromeFlags
			}
		},
    });
};

Y este será el resultado en nuestro proyecto en este punto:

Modificando los ficheros de QUnit para Github (docker)

El siguiente punto es un poco extraño, de hecho, para que veáis la dificultad a veces de escribir un post, encontrar el error de este punto me costo unas 4 horas.

Lo que haremos es cambiar las rutas relativas de los ficheros en la ruta”/webapp/test/”:

  • “/testsuite.qunit.html”
  • /unit/unitTests.qunit.html

Para esta prueba solo utilizaremos QUnit no los test OPA por lo que iremos al fichero “testsuite.qunit.js” y comentaremos la línea que invoca los test de OPA:

Añadiendo el nuevo script para invocar Karma

El último paso en nuestro proyecto sera añadir en el fichero package.json los script de lanzamiento de Karma. Para ello añadiremos estos dos scripts:

"karma-ci": "karma start karma-ci.conf.js",
"test": "npm run karma-ci"

Este es el resultado:

Ya podemos subir a nuestro repositorio Git los cambios que hemos ido haciendo.

Un cambio extra que deberemos hacer en el fichero package.json será mover las librerías que están en el apartado “devDependencies” a “dependencies”.

Por último, añadiremos esto al final del fichero

    "optionalDependencies": {
        "fsevents": "^2.3.2"
    },
    "devDependencies": {
        "qunit": "^2.17.2"
    }

Haciendo un poco de resumen este es mas o menos el aspecto final:

{
    "name": "karmaqunit",
    "version": "0.0.1",
    "private": true,
    "description": "A Fiori application.",
    "keywords": [
        "ui5",
        "openui5",
        "sapui5"
    ],
    "main": "webapp/index.html",
    "dependencies": {
        "karma": "^6.3.9",
        "karma-chrome-launcher": "^3.1.0",
        "karma-cli": "^2.0.0",
        "karma-coverage": "^2.1.0",
        "karma-ui5": "^2.4.0",
        "puppeteer": "^12.0.1",
        "rimraf": "^3.0.2",
        "@sap/ui5-builder-webide-extension": "1.0.x",
        "@sap/ux-ui5-tooling": "1",
        "@ui5/cli": "^2.12.0",
        "mbt": "^1.0.15",
        "ui5-task-zipper": "^0.3.1"
    },
    "scripts": {
        "start": "fiori run --open 'test/flpSandbox.html#ecastellakarmaqunit-display'",
        "build": "ui5 build --config=ui5.yaml --clean-dest --dest dist",
        "deploy": "fiori cfDeploy",
        "deploy-config": "fiori add deploy-config",
        "start-local": "fiori run --config ./ui5-local.yaml --open 'test/flpSandbox.html#ecastellakarmaqunit-display'",
        "start-noflp": "fiori run --open 'index.html'",
        "start-variants-management": "fiori run --open \"preview.html?fiori-tools-rta-mode=true&sap-ui-rta-skip-flex-validation=true#preview-app\"",
        "unit-tests": "fiori run --open test/unit/unitTests.qunit.html",
        "int-tests": "fiori run --open test/integration/opaTests.qunit.html",
        "build:cf": "ui5 build preload --clean-dest --config ui5-deploy.yaml --include-task=generateManifestBundle generateCachebusterInfo",
        "build:mta": "rimraf resources mta_archives && mbt build",
        "undeploy": "cf undeploy ecastella-karmaqunit --delete-services --delete-service-keys",
        "karma-ci": "karma start karma-ci.conf.js",
        "test": "npm run karma-ci"
    },
    "ui5": {
        "dependencies": [
            "@sap/ux-ui5-tooling",
            "@sap/ui5-builder-webide-extension",
            "ui5-task-zipper",
            "mbt"
        ]
    },
    "sapuxLayer": "CUSTOMER_BASE",
    "optionalDependencies": {
        "fsevents": "^2.3.2"
    },
    "devDependencies": {
        "qunit": "^2.17.2"
    }
}

Añadiendo la configuración el en proyecto UI5

Tenemos que modificar el fichero “ui5.yaml” para añadir las opciones del framework:

resources:
    configuration:
        paths:
            webapp: webapp
framework:
    name: SAPUI5
    version: 1.76.1
    libraries:
        - name: sap.ui.core
        - name: sap.m
        - name: sap.f
        - name: sap.tnt
        - name: sap.ui.layout
        - name: themelib_sap_fiori_3

El último paso es refrescar el fichero package-lock.json para ello tenemos vamos a ejecutar el comando npm install

Con todo esto ya podemos sincronizar nuestro repositorio.

Creando la rama DEV para hacer Pull request y los labels

En este ejemplo utilizaremos dos ramas para poder realizar un pull request. Aquí podéis dejar volar vuestra imaginación ya sea con diferentes ramas, forks, etc…

Para crear una nueva rama en Github vamos al selector de ramas y escribimos el nombre que queremos darle a nuestra rama:

Lo que vamos a hacer es añadir un tag en el pull request si pasamos los test ejecutados por QUnit. Para ello, crearemos también un Tag situándonos en “Issues” y después pulsando en “Labels”

Pulsamos el botón “Create label”

Creando la configuración de Actions

Lo siguiente es revisar si las acciones están permitidas en nuestro repositorio (por defecto sí), para ello vamos a Settings – Actions, tenemos que ver lo siguiente:

Ya podemos crear la lista de instrucciones que necesitaremos para ejecutar nuestras acciones, vamos al botón actions y crearemos un workflow de 0:

Estos son los pasos que añadiremos en el fichero de configuración yml:

name: Pull request UT testing

on:
  pull_request:
   branches: [ main ]

env:
  FORCE_COLOR: 2

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        node: [14]

    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node }}
          
      - name: Install npm dependencies
        run: npm ci
        
      - name: Run tests
        id: test
        run: npm run test
        continue-on-error: true
        
      - name: UT Pass adding comment
        uses: thollander/actions-comment-pull-request@v1
        if: steps.test.outcome == 'success'
        with:
           message: "Congratulation you past the UT!"
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           
      - name: UT Pass adding tag
        if: steps.test.outcome == 'success'        
        uses: actions-ecosystem/action-add-labels@v1
        with:
           labels: UT pass

Así es como se vería en Github.

Antes de seguir, analicemos un poco lo que hemos añadido:

  • En la instrucción ON indicamos que queremos que este workflow se dispare solo cuando hagamos un pull request sobre la rama main. Podemos también condicionar a que se disparen con push sobre ramas concretas por ejemplo.
  • En jobs/build indicamos la version de imagen o OS que queremos utilizar así como indicar una matriz de versiones de node.js, en este caso solo la 14
  • Steps empieza con la configuración mínima para iniciar node.js
  • Install npm dependencies nos permite instalar todas las librerías contenidas en el fichero package.json
  • Run test ejecutara el script que hemos configurado para arrancar Karma
  • las dos ultimas instrucciones, añadirán un comentario y el tag solo si el paso “Run test” ha sido ejecutado de manera correcta.

Con todo esto ya podemos pulsar los botones “Start commit” y “Commit new file”. Esté será el resultado:

Probando el nuevo workflow

Ya tenemos todo listo, solo nos queda ejecutar un pull request para ver los resultados.

Creando un pull request

Vamos a la rama “Dev” creada anteriormente

Y modificamos alguna cosa, para hacerlo fácil, añadiremos una nueva línea en el fichero read.me:

Añadimos el “nuevo” contenido y pulsamos commit changes:

Ahora vamos a generar un nuevo Pull request:

Seleccionamos como rama origen “dev” para mandar a “main” y pulsamos “Create pull request”

Añadimos un comentario si lo consideramos y otra vez “Create pull request”:

Con estos cambios veremos que se inicia los checkeos de QUnit de manera automática

Si todo ha ido bien, veremos al rato que la validación ha pasado:

Y este será el resultado:

Si vamos a la pestaña actions, veremos nuestro nuevo workflow y el resultado:


Como veis gracias a las acciones de Github podemos ejecutar de manera automática el testing de nuestra aplicación a fin de facilitar la revisión de la estabilidad de la aplicación cuando se realiza un pull request.

Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última. Vota Like / Dislike para aportar feedback.

2 respuestas a «Qunit automático con Github actions»

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.