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 rimrafEste 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_3El ú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 passAsí 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.
No quiero saber las horas totales que te ha llevado escribir esto… 😉
¡Gracias por compartir!
Pues quizás uno de los mas complicados, pero lo he pasando en grande investigando
Muchas gracias!