2. - Jest como herramienta de Testing
- Instalar y Configurar Jest
- Estructura de los test
- matchers
- Corriendo los test
- Creando un test
- Configurar el Web Inspector
- Debugging con el Inspector de Chrome o VS Code
Agenda
4. Testing & Debugging LWC
Jest
Vamos a utilizar Jest, es un Testing Framework que sirve para escribir Unit Tests de nuestros
LWC.
Vamos a usar el modulo npm lwc-jest que instala todo lo necesario para configurar Jest para un
proyecto de Salesforce DX.
Se corren desde la linea de comandos o desde el IDE. No corren en el navegador, ni se conectan
al org, por lo que se ejecutan muy rápido.
5. Testing & Debugging LWC
Jest
Al enfocarse en simplicidad, nos facilita varias cosas.
- Cero configuración: Apunta a funcionar sin necesidad de configuración en la mayoría de
proyectos JavaScript.
- Paralelismo: Los test corren en su propio proceso para maximizar el rendimiento.
- Una gran API: Desde it hasta expect, Jest tiene el toolkit completo con muy buena
documentación.
- Seguro: Cada test tiene un global state único, lo que asegura que puedan correr en paralelo de
manera confiable.
- Rápido: Jest ejecuta primero los test que fallaron anteriormente y reorganiza los tests
basandose en lo que demoro en ejecuciones anteriores.
6. Testing & Debugging LWC
Instalando lwc-jest
Como prerequisito vamos a necesitar Node.js y npm.
Por defecto, los proyectos de Salesforce DX no cuentan con un package.json, lo podemos
crear ejecutando en el nivel mas alto del proyecto:
npm init
Una vez creado el package.json, vamos a instalar lwc-jest y sus dependencias
npm install
npm install @salesforce/lwc-jest --save-dev
7. Testing & Debugging LWC
Luego vamos a necesitar editar el
package.json para agregar el script a ejecutar.
En la sección scrips ponemos un codigo como
el siguiente:
Para ejecutar todos los test, vamos a ejecutar
el comando que agregamos en scripts:
npm run test:unit
Para correr todos los test de un componente
especifico y cada vez que se guarden los
cambios, cambiamos al directorio del
componente y ejecutamos el comando con el
flag --watch.
npm run test:unit:watch
Instalando y corriendo lwc-jest
Los flag --watch y --
debug son opcionales
8. Testing & Debugging LWC
Vamos a crear una carpeta de nombre __tests__ en el nivel mas alto del directorio del
componente. Guardamos todos los tests del mismo componente dentro de su carpeta __tests__.
El nombre de los archivos va a terminar con extension .js, y se recomienda nombrarlos de manera
que terminen en .test.js. Se pueden tener un archivo con todos los tests, o bien varios archivos.
Estructura
9. Testing & Debugging LWC
Vamos a crear una carpeta de nombre
__tests__ en el nivel mas alto del directorio del
componente. Guardamos todos los tests del
mismo componente dentro de su carpeta
__tests__.
El nombre de los archivos va a terminar con
extension .js, y se recomienda nombrarlos de
manera que terminen en .test.js. Se pueden
tener un archivo con todos los tests, o bien
varios archivos.
Estructura
10. Testing & Debugging LWC
Jest utiliza "matchers" para testear valores de
diferentes maneras.
La manera mas sencilla de testear la igualdad
de un valor.
Esto devuelve una "expectation" o espectativa
sobre la cual llamariamos a los matchers.
Algunos de los matchers
.toBe - para chequear variables
.toEqual - para chequear objetos
.toBeNull()
.toBeDefined();
.not.toBeUndefined();
.not.toBeTruthy();
.toBeFalsy();
.... la lista completa
https://jestjs.io/docs/en/using-matchers.html
matchers
11. Una de las cosas con las que nos enfrentamos al desarrollar LWC es lo que Salesforce llama el production
mode, que es cómo expone los componentes al usuario;
• Minified JavaScript
• Proxied values
Testing & Debugging LWC
Lightning Web Components in production mode
12. Todos archivos JavaScript de los Lightning Web Components que el browser recibe de Salesforce en
"production mode" son "minified".
Fácilmente, se puede usar cualquier opción para darle un formato mas amigable, esto se puede ver en las
herramientas de desarrollo del browser que utilicen.
Testing & Debugging LWC
Minified JavaScript
13. Ciertas cosas, vienen bajo un "proxy", como los datos que son proporcionados mediante "decorators" (@api,
@track, @wire).
Algunos son considerados "read-only", @api y @wire. Asi que mediante JavaScript Proxies, Salesforce se
asegura que aun siguen siendo read-only.
Para @track, los proxies se usan para observar la mutacion de la data.
Testing & Debugging LWC
Proxied values
14. Ademas de production mode, se puede habilitar debug mode para usuarios especificos.
Debug mode tiene algunas nuevas cosas que no existian para Aura components:
• Unminified JavaScript
• Custom formatting
• Developer mode console warnings
Testing & Debugging LWC
Lightning Web Components in debug mode
15. Unminified JavaScript in debug mode es lo mismo que decir que vamos a ver lo que
codificamos en nuestro IDE, igualmente en nuestro browser.
Testing & Debugging LWC
Unminified Javascript
16. Habiamos visto anteriormente que los JavaScript proxies hacen que ciertos tipos de data sean read-only.
Para simplificar la lectura, se puede utilizar un formato personalizado.
Ejemplo: Chrome DevTools => Settings => Enable custom formatters
Testing & Debugging LWC
Custom formatting
17. Pausar en excepciones de JavaScript, para esto en Chrome por ejemplo podemos habilitar la opción:
Pause on exceptions
Para evitar que estemos pausando en cada excepción, podemos usar blackboxing, agregando las
siguientes expresiones regulares para ver los errores que suceden en nuestro código;
/aura_prod.*.js$
/components/.*.js$
Testing & Debugging LWC
Console warnings and exceptions
18. Inspeccionar los test para ver como se comporta el código durante la ejecución;
a. Chrome Dev Tools Inspector
b. Debug con Visual Studio
Testing & Debugging LWC
Debugging jest tests