Dominando Node.js Test Runner

Rate this content
Bookmark

Node.js test runner es moderno, rápido y no requiere bibliotecas adicionales, pero entenderlo y usarlo bien puede ser complicado. Aprenderás a utilizar Node.js test runner a su máximo potencial. Te mostraremos cómo se compara con otras herramientas, cómo configurarlo y cómo ejecutar tus pruebas de manera efectiva. Durante la masterclass, haremos ejercicios para ayudarte a sentirte cómodo con el filtrado, el uso de afirmaciones nativas, la ejecución de pruebas en paralelo, el uso de CLI y más. También hablaremos sobre trabajar con TypeScript, hacer informes personalizados y la cobertura de código.

78 min
19 Dec, 2023

AI Generated Video Summary

Esta masterclass introduce Node.js Test Runner y sus características, incluyendo filtrado, subtesting, informes, marcado, modo de observación y cobertura de código. Los participantes necesitan Node.js 20 o 20.9 LTS y Git. Test Runner es rápido y simple, se envía dentro del binario de Node.js y puede ser utilizado como punto de partida para otras bibliotecas. Soporta el filtrado de pruebas por patrón de nombre y ofrece una potente biblioteca de afirmaciones. También proporciona características como pruebas en paralelo, ganchos de prueba, simulacros, informes personalizados, soporte para TypeScript y cobertura de pruebas. El sharding permite una ejecución eficiente de las pruebas en varias máquinas.

1. Introducción al Node.js Test Runner

Short description:

Bienvenidos a mi masterclass sobre el nuevo Node.js Test Runner. Soy Marco Ippolito, un mantenedor de Node.js en NearForm. Esta masterclass se divide en dos partes. La primera parte presenta el Test Runner y su importancia. La segunda parte cubre las principales características, incluyendo el filtrado, subtesting, informes, marcado, modo de observación y cobertura de código. Para participar, necesitarás Node 20 o 20.9 LTS y Git.

Bienvenidos a todos a mi masterclass. Hoy vamos a hablar sobre el nuevo Node.js Test Runner. Permítanme presentarme. Mi nombre es Marco Ippolito. Soy uno de los mantenedores de Node.js. Trabajo en NearForm como Ingeniero Senior de Developer Experience. Y hago muchas actividades de código abierto, principalmente relacionadas con el ecosistema de Node.js.

Así que esta masterclass se divide en partes principales. La primera es muy pequeña. Es solo una pequeña introducción sobre el Test Runner en sí. ¿Qué es el Test Runner? ¿Por qué lo necesitamos? Y luego pasaremos a las partes prácticas, ejercicios, y aprenderemos un poco sobre cómo usar esto. El ejercicio va a ser bastante simple, así que nada loco, pero te ayudará a entender todas las características del Node.js Test Runner. Así que empecemos. Si tienes alguna pregunta o quieres saber algo sobre lo que soy, quieres que amplíe algo, por favor escribe en el chat, levanta la mano, y nos detendremos y lo discutiremos. No te preocupes.

Hay una charla mía que está grabada desde el TestJS Summit sobre el Test Runner. Va a ser, es más, cubrirá la teoría más en profundidad. Así que échale un vistazo y empecemos. Así que en Test Runner, cuando hablamos de este runner, hablamos de esa herramienta CLI que entra en tu código fuente y ejecuta el archivo marcado como test, normalmente con una extensión .test.js o .spec.js. Pero el Test Runner, es en realidad la herramienta CLI, y entra en tu código fuente y simplemente ejecuta el archivo, así que esa es la parte que Node.js estaba perdiendo. Hay muchos test runners y test frameworks, como demasiados. Y Node.js en el pasado solo enviaba una biblioteca de aserciones. Veremos qué es una biblioteca de aserciones más tarde, pero es cuando compruebas si algo es igual a algo más o no es igual, etcétera, etcétera. Así que es solo para comprobar, pero Node en sí no podía ejecutar pruebas. Necesitaba una biblioteca externa como Mocha, TAP, o los mil millones de frameworks y bibliotecas de testing que están en el ecosistema de JavaScript. Así que Node.js necesitaba un test runner. Era hora, porque era el único runtime que no lo tenía. Y también necesitaba un framework de pruebas. Eso es un framework de pruebas. Es lo que escribes dentro de tus archivos de prueba para programar la ejecución de la prueba. Así que por ejemplo, eat, describe, only, los hooks, before, eso es todo parte del framework de testing. Así que es lo que está dentro del código, mientras que lo que ejecuta el código es el test runner. Así que el Node.js envió el test runner desde Node 20, y ahora está disponible para todos. Node 20.9 es LTS ahora, así que definitivamente deberías usarlo. Si estás usando una versión antigua, deberías migrar. Es muy importante. Oops. Oh, ¿qué? No. Eso no es lo que quería. Vale. Sí. Así que en esta masterclass, repasaremos las principales características de este nuevo test runner y framework de testing. Así que veremos tanto la parte CLI, como la parte del framework de testing. Veremos el filtrado, subtesting, informes, marcado, modo de observación y cobertura de código.

2. Configuración y Estructura de la Masterclass

Short description:

Para participar en esta masterclass, necesitarás Node 20 o 20.9 LTS y Git. Clona el repositorio proporcionado, navega hasta la carpeta de origen y elige un ejercicio de las 11 carpetas disponibles. Cada ejercicio tiene instrucciones en su archivo readme. En el ejercicio de ejemplo, encontrarás tres funciones simples: sum, product y average. Estas funciones se utilizarán en la mayoría de los ejercicios. También hay archivos de prueba para cada función.

Les contaré algunas anécdotas de los proyectos de Node.js, algunos chismes sobre esta característica, y cómo evolucionaron y qué se necesitó. Así que comencemos con los requisitos. Necesitamos en nuestras máquinas, necesitamos Node 20, el LTS o Node 20.9, y necesitamos Git.

Así que si hay alguien que no tiene estos dos requisitos en su máquina, por favor levante la mano, y esperaremos. De lo contrario, continuaremos. Así que está bien. Así que asumo que todos tienen Node 20 y Git. Como si no tuvieras Git, eso sería raro. Así que está bien. Pegué un enlace en el chat, y puedes simplemente copiar y pegar la URL del repositorio. Así que necesitamos navegar a esta URL. Lo escribiré en el chat. Así que por favor clona este repositorio que pegué en el chat y ejecuta NPM install. Esperaré dos minutos. Si han pasado dos minutos y aún no has instalado, por favor levanta la mano o escribe en el chat. Esperaré un poco más de tiempo.

Bien, simplemente navega a la URL, clona el proyecto y ejecuta NPM install. ¿Cómo está estructurada esta masterclass? Hay 11 carpetas, 11 ejercicios. Así que el primero es un ejemplo, pero los discutiremos juntos, y puedes ejecutarlos. Así que si vas a la carpeta de origen del proyecto, verás que hay 11 carpetas desde A0 hasta A10. Así que primero, haremos cd en la carpeta 0. Las soluciones a los problemas están en el package.json como un script de solución o están en el archivo solution.js. Así que si quieres, si no puedes resolverlo y quieres echar un vistazo a la solución, está ahí. Pero si no, simplemente no lo abras para que no te arruine la solución. Y hay instrucciones en el readme para cada ejercicio, así que si pierdes algo, puedes simplemente ir al readme del ejercicio y leer las instrucciones allí.

Bien, vamos a nuestro código. Así que deberíamos chatear aquí. Bien, esto es lo que, cuando clonamos el proyecto, debería parecer. Así que ejecutamos NPM install. ¿Es demasiado pequeño? ¿Debería acercar un poco? Avísame. ¿Mejor? Supongo que está bien. Está bien, vale. Bien. De acuerdo. Así que podemos hacer cd en la carpeta de origen. Y podemos hacer cd en la A00, la de ejemplo. Bien. Así que vamos al ejemplo 00 y vamos al readme. Bien, las instrucciones son simples. Vamos al archivo index.js. Podemos ver que hay tres funciones. Hay sum, hay product, y hay average. Estas tres funciones se van a utilizar en, creo que en la mayoría de los ejercicios, vamos a utilizar estas tres funciones porque son simples y, así que una simplemente toma un array de números y hace la suma de cada elemento. Si no es un array, lanza un error. La otra hace el producto de cada elemento de un array. Y la última hace la media. Así que tres funciones simples. Bien. Luego está la carpeta de pruebas donde vamos a ejecutar nuestras pruebas. Y así puedes ver que hay tres pruebas, una para sum, una para product, una para average.

3. Estructura del Test Runner de Node.js

Short description:

Esta es la estructura de nuestra masterclass. El Test Runner de Node.js es rápido y sencillo. Se incluye dentro del binario de Node.js. Fue creado como un punto de partida para otras bibliotecas. El ecosistema está creciendo rápidamente. Ejecutamos Node.js para ver las pruebas. Abrimos el readme y encontramos las funciones. Especificamos la carpeta personalizada y el archivo de prueba utilizando flags. Ahora hemos ejecutado nuestras pruebas especificando una carpeta personalizada.

Esta va a ser la estructura de nuestra masterclass que se ejercitará en base a esta función. También hay otros tipos de funciones, pero todas son bastante similares. ¿Cómo funciona? ¿Cómo ejecutar el Test Runner de Node.js? No menos, menos, más. Ahí vamos.

Lo genial del Test Runner es que es increíblemente rápido comparado con todas las otras bibliotecas porque está en el núcleo y es muy, muy rápido. Es simple. Se incluye dentro del binario de Node.js. Así que ya lo tienes en tu máquina y definitivamente deberías usarlo. Y lo bueno es que este Test Runner fue creado como un punto de partida para que otras bibliotecas se construyan encima. Así que en términos de funcionalidad, no hay muchas comparadas con Jest o VTest. Pero el ecosistema está creciendo rápidamente.

Así que si ejecutamos Node.js, deberíamos ver las tres pruebas que ejecuto y todas pasan. Avísame si alguien tiene algún problema. Como siempre, levanta la mano, escribe preguntas en el chat, lo que sea. Si no puedes, como si por alguna razón este Node.js no funciona para ti, avísame para que no continúe asumiendo que funciona para todos, ¿de acuerdo? ¿No hay problemas hasta ahora? Vale. Así que este fue un ejemplo. Fue muy fácil. Así que si seguimos el readme, veremos que tenemos que abrir el archivo test.js. Hay tres pruebas. Ejecutamos Node.js y vemos el resultado. Así que ahora vamos al primero. Así que volvemos y vamos al 801. Este es el 801 que trata sobre el filtrado. Así que abramos el readme. Así que abrimos la búsqueda de archivos en Node.js y vemos las tres funciones del ejercicio, el ejercicio anterior. Pero ahora la carpeta cuando ejecutamos nuestra prueba ha cambiado. Así que si ejecutamos Node.tests, veremos que Node.tests ha sido ejecutado. Esto se debe a que el Test Runner espera que la prueba esté bajo la carpeta de pruebas. Mientras que en nuestro caso, están bajo la carpeta de pruebas personalizada. Así que tenemos que decirle al Test Runner que hemos cambiado de ubicación. Así que si entramos, vemos que la extensión del archivo es .spec.js. El Test Runner de Node.js no sabe que .spec.js significa un archivo de prueba. Solo reconoce .tests.js. Así que no sabe qué ejecutar. Así que necesitamos ejecutar el archivo de prueba, pero necesitamos hacerle saber al Test Runner dónde está la carpeta y qué prueba queremos ejecutar. Y en este caso particular, solo queremos ejecutar esta llamada producto. ¿Cómo hacemos esto? Así que necesitamos usar el flag test pattern para especificar qué nombre de prueba queremos ejecutar. Por ejemplo, si usamos un patrón de prueba producto, pasará por todas estas pruebas y ejecutará solo la que coincida con esta. Así que si escribes test pattern product, test pattern equals product. Y si escribes test name pattern equals product, lo comprobará. Ahora no funcionará porque todavía no puede encontrar la carpeta. Así que si ejecuto esto, no hay nada. Todavía espera que las pruebas estén bajo la carpeta de pruebas, pero están en otra ubicación. Así que necesitamos decirle al Test Runner que busque en otro lugar, y podemos simplemente escribir carpeta. Vale, todavía nada. ¿Por qué? Porque aunque le dijimos al Test Runner qué carpeta queremos ejecutar nuestra prueba, no está esperando la extensión .spec.js. Así que necesitamos decirle que mire los archivos que terminan con .spec.js. Así que hacemos esto. Vale, ahora funciona. Así que ahora hemos ejecutado nuestras pruebas especificando una carpeta personalizada.

4. Patrón de Nombre de Prueba y Afirmaciones

Short description:

Si quieres ejecutar una prueba específica relacionada con una función, puedes filtrar por patrón de nombre de prueba. Esto es útil cuando tienes múltiples pruebas en un archivo y quieres ejecutar solo una específica. Las afirmaciones en la biblioteca de afirmaciones de Node.js incluyen igualdades estrictas y versiones negadas. Se recomienda usar igualdad estricta profunda para comprobaciones de triple igualdad. Las funciones asíncronas rechazan en lugar de lanzar, por lo que se deben usar operadores diferentes. Tómate un par de minutos para experimentar con las afirmaciones, y luego discutiremos las soluciones.

Si elimino el patrón de nombre de prueba, ejecutará todos ellos. Así que tres archivos ejecutados, tres pruebas ejecutadas con el cambio de patrón de nombre de prueba, y puedes hacer cosas muy interesantes. Esto es muy útil si quieres ejecutar, por ejemplo, tienes muchas pruebas y en un solo archivo y quieres ejecutar solo una relacionada con una función específica. Por ejemplo, imagina que tengo como 100 pruebas. Así que quiero ejecutar solo una relacionada con la función sum. Así que filtro por patrón de nombre de prueba igual a sum. Así que si el nombre de la prueba contiene esa cadena, ejecutará solo ellas. Esto es muy útil. Por lo general, todas las pruebas relacionadas con una sola característica tendrán algunas partes del nombre que son comunes, y esto te ayudará a filtrar.

¿Esto tiene sentido para todos? ¿Algún problema hasta ahora? Si no, por favor levanta la mano, haz tu pregunta. Estoy aquí por esta razón muy específica.

Bien, vamos al número dos. Así que las afirmaciones, como siempre, abrimos el readme. Así que abrimos el archivo index.js. Bien, veremos dos funciones. Una es sum, y una es sumAsync. Hacen lo mismo, solo que esta es asíncrona, por lo que devolverá una promesa. Bien, así que en la carpeta de pruebas, dos archivos. Uno es el actual y el otro es la solución. Así que si quieres conocer la solución, puedes simplemente abrir el archivo de solución, pero probablemente esperaremos. Así que abrimos el archivo de prueba index. Estas son todas las afirmaciones disponibles en la biblioteca de afirmaciones de Node.js. En realidad, faltan dos, una que falta es AssertIfAs. AssertIfError. Y hay, esta se puede negar con AssertNotDistrictEqual. Así que cada afirmación tiene la negativa, lanza no lanza, rechaza no rechaza, coincide no coincide. Te sugiero que siempre uses igualdades estrictas. Así que por ejemplo, en la biblioteca de afirmaciones de Node.js, hay AssertEqual, AssertDeepEqual. Pero, y dije, la igualdad estricta, y la diferencia entre, la diferencia entre el operador de doble igual y el de tres. Así que con deep strict equal, estás haciendo la comprobación de triple igualdad, la comprobación de igualdad fuerte, con deep strict equal, con deep equal, estás haciendo solo los dos operadores iguales. Así que esa es una gran diferencia. Así que siempre deberías usar la igualdad estricta profunda.

Bien, entonces escribamos algunas afirmaciones basadas en los comentarios aquí. Así que en este caso, no lo mostraré. Y esperaré dos minutos para que juegues con él. Y luego pasaremos a la solución, y veremos y discutiremos un poco sobre las afirmaciones y demás. Bien, así que te daré dos minutos, si tienes alguna pregunta. Como siempre, simplemente levanta la mano o escribe un comentario en el chat. Lo leeré. Y la principal diferencia es que, una función asíncrona no lanza, sino que rechaza. Así que deberías usar diferentes operadores basados en lo que estás haciendo. Si estás trabajando con asincrónico, deberías usar rechazar. No rechaza. Si no, deberías usar lanzar o no lanzar. Te daré un par de minutos para jugar con esta afirmación. Son bastante simples. Y luego iremos al archivo de solución y veremos, discutiremos las posibles soluciones. Esta parte es en realidad igual a todo tipo de bibliotecas de afirmaciones. Muy estándar, no tiene nada sofisticado. Así que lo bueno es que no necesitas como, Xenon, bibliotecas de terceros para hacer esta prueba, porque tienes todo dentro de Node.

5. Características y Afirmaciones del Node.js Test Runner

Short description:

La función de instantánea en Node.js 18 permitió hacer pruebas de instantáneas de los resultados, pero fue eliminada debido a su inestabilidad. La biblioteca de afirmaciones permite comentarios descriptivos, comprobaciones de igualdad estricta profunda y comprobaciones de instancias de errores. Es importante envolver las funciones en funciones de flecha cuando se utiliza throws o does not throw. Crear una instancia de un error y comprobar si es una instancia puede ser más rápido que comprobar el mensaje o el código. Para las funciones síncronas, se debe utilizar async y await para comprobar si se rechaza o no se rechaza. Las funciones match y does not match son útiles para ejecutar regex en cadenas.

Y lo interesante que también estaba en Node 18, estaba la instantánea, el match snapshot. Así que podrías hacer una instantánea del resultado de tu prueba y comprobar la calidad, pero fue eliminada, porque no era lo suficientemente estable. Así que las instantáneas son una gran característica que realmente echo de menos. Y probablemente las veremos volver.

Así que, vale, se acabó el tiempo. Vamos a la solución. Ahora podemos verla juntos. Así que también podemos optar por importar todo desde strict. Así que ser estrictos con nuestra sesión simplemente importando slash strict. Te sugiero que hagas esto. Siempre importa desde la parte estricta. Así que no tienes la oportunidad de cometer errores.

Vale, lo interesante de las bibliotecas de afirmaciones es que puedes comprobar la igualdad aquí, y luego tener el comentario sobre lo que exactamente está haciendo. Esto es muy útil para, para ser descriptivo cuando estás haciendo algo. La prueba ya es, como cuando una prueba falla, y ni siquiera sabemos qué está pasando, es realmente difícil. Así que puedes añadir un comentario a la derecha para decirle a otros colegas, como ¿qué está pasando? ¿Por qué, qué está buscando realmente esta prueba? Y creo que esta es una de las, como una característica muy útil. Así que usamos la igualdad estricta profunda para comprobar la suma de uno, dos, tres, seis. El tipo de retorno es un número, y luego comprobamos, este es nuestro caso límite. Y queremos comprobar que si el array está vacío, no lanza. Cuando escribes throws o does not throw, necesitas usar, necesitas envolver la función dentro de una función de flecha. Lo mismo para si el resultado de un array vacío es cero para el caso límite, y este es uno que comprueba que si envuelvo algo que no es un array de números, lanzará, y comprueba el mensaje.

No aconsejo que siempre compruebes, dependiendo, depende mucho. Así que si usas un error como este, entonces quieres comprobar el mensaje. Pero si creas un personalizado, por ejemplo, creamos una clase custom error, y la exportamos. Export class custom error. F extent, y hacemos construct. Tenemos m como mensaje. Inglés, vale. Formateo, sí, esto no es necesario. Y luego podemos usar este error aquí. Lo interesante es que dentro del Node.js runner, el nivel de afirmación, puedes comprobar si esto es una instancia de custom error. Así que necesitamos, vale, y hacemos node minus test, y funciona. Esto es, así que normalmente hago esto. Normalmente creo una instancia de un error, y luego en lugar de comprobar el mensaje o el código, simplemente compruebo si es una instancia. Tiene sus inconvenientes, obviamente, pero creo que de esta manera es más rápido. Y si, como, normalmente los mensajes de error cambian con el tiempo. Así que no lo aconsejo. Mientras que en la función síncrona, obviamente, necesitas escribir sync al principio de la prueba. Puedes comprobar. Puedes esperar. Así que es como siempre, y luego tienes que comprobar. Does not reject, rejects. Y es lo mismo que work, pero necesitas tener cuidado. Recuerda esperar el rechazo. De lo contrario, no funcionará, y sería un poco incómodo, el error que produce si no esperas esta función aquí. Así que recuerda esperarlo. Y luego esto es solo para mostrarte el match y does not match. Esto también es muy útil. Es un regex. Puedes ejecutar el regex en la cadena.

6. Pruebas Paralelas y Concurrencia

Short description:

La biblioteca de afirmaciones en JS es pequeña pero poderosa, con todas las características principales excepto las instantáneas. ¿Alguna pregunta hasta ahora? Ahora, pasemos al ejercicio número tres: pruebas paralelas. En este ejercicio, tenemos dos funciones con tiempos de espera establecidos. ¿Sabías que puedes crear una función de suspensión sincrónica en Node.js sin importar nada? Es muy útil. Al comprobar la concurrencia y ejecutar pruebas en paralelo, podemos reducir significativamente el tiempo de ejecución. Utiliza los núcleos disponibles en tu máquina para acelerar las pruebas. Node.js Test Center también comprueba la concurrencia por defecto, utilizando el número de núcleos de CPU disponibles menos uno.

Por ejemplo, para comprobar. Esto es realmente bueno para comprobar el mensaje de error si contiene un código o algo simplemente coincides o no coincides. Así que estas son las, esta es la biblioteca de afirmaciones en JS. Es muy pequeña, pero tiene todas las cosas excepto las instantáneas. Realiza todas las características principales.

Vale. Entonces, ¿alguna pregunta hasta ahora? Creo que esto es, está claro. Si tienes preguntas, lo que sea, simplemente escribe en el chat. Lo leeré inmediatamente.

Vale, ahora, ejercicio número tres, pruebas paralelas. Esto es interesante. Así que si abrimos el archivo, si abrimos el archivo en next.js, veremos que hay dos funciones. Una hace la suma y la otra hace el producto, pero tienen un tiempo de espera establecido. ¿Cuántos de ustedes sabían que pueden crear una función de suspensión sincrónica en Node.js sin importar nada? Esto está dentro de Node. No necesitas crear nada. Normalmente lo que hacemos es, en suspensión, y hacemos algo como esto. Bien. Tiempo de espera establecido. Así es como normalmente hacemos para crear una función de suspensión. Y esta es la misma cosa, hace lo mismo. Y está dentro de los temporizadores de nodo / promesas. Y es solo una función de suspensión. Es muy útil si no sabías sobre ello. Es muy útil. Bien. Así que como puedes ver, tenemos esta función que tarda mucho tiempo en ejecutarse. Así que significa que nuestra prueba también tardará mucho tiempo en ejecutarse. Así que si ejecutamos Node.js prueba concurrencia uno, verás cuánto tiempo tarda. Porque está haciendo, está ejecutando la prueba una por una, paso a paso. Así que si miramos la prueba, hay muchas pruebas aquí y simplemente las hacen una por una. Está tomando una cantidad de tiempo increíble. Pero lo interesante es que podemos ejecutar la concurrencia. ¿Y cómo podemos hacer eso? En primer lugar, necesitamos comprobar la concurrencia. En primer lugar, necesitamos comprobar cuántos núcleos tenemos en nuestra máquina. Mi máquina tiene 10 núcleos. Así que el resultado será 10. Esto es nodo menos E, significa evaluar. Así que ejecutará la cadena que usaste. Y en este caso, solo estoy usando el módulo OS de nodo para comprobar el paralelismo disponible. Así que es 10. Así que significa que puedo ejecutar nodo prueba concurrencia 10 y tomará una fracción de lo que tomó al principio. Así que, sí, ya está hecho. Tomó seis segundos mientras que la primera iteración. Sí, todas tomaron seis segundos y la primera iteración, mucho, mucho más que eso. Así que te sugiero que lo uses cuando ejecutes pruebas. Si usas el Centro de Pruebas de Node.js, también comprueba la concurrencia, comprueba qué núcleos están disponibles. Node.js lo hace por defecto. Así que si ejecutas nodo menos prueba, lo hará por defecto. Y el valor será el número de núcleos de CPU disponibles menos uno.

7. Concurrencia y Ejecución de Pruebas

Short description:

Concurrency true es una opción útil para asignar recursos a las pruebas de Node.js. Se puede pasar como argumento para acelerar las pruebas sincrónicas. Siempre recuerda hacer await a las pruebas, especialmente en escenarios de subpruebas.

Entonces, este es un truco genial. Y probablemente si tienes máquinas grandes, no querrás asignar toda la memoria a Node.js. Por ejemplo, no querrás asignar a todos los núcleos a Node.js, pero quieres afinar esto dependiendo de dónde lo estés ejecutando. Pero es muy útil. Y también puedes escribirlo aquí. Puedes escribir concurrency true como una opción para la prueba. Y esto habilitará el mismo mecanismo por defecto, pero será como, la bandera CLI lo anulará. Entonces, generalmente, cuando estás ejecutando una prueba sincrónica, siempre querrás tener concurrency true, porque acelerará mucho. Puedes pasarlo como argumento aquí en las pruebas. Además, asegúrate de que siempre haces await a tus pruebas. Si es grande, si estás haciendo subpruebas, tienen una grande, y luego tienes una prueba más pequeña dentro, querrás hacerles await. Si no, sucederán muchas otras cosas. Esto obviamente solo si es una prueba asíncrona. Si es sincrónica, no tiene sentido.

8. Refactorización de Pruebas con Hooks y Filtrado

Short description:

Esta es una nueva característica que acelera las pruebas. Podemos refactorizar las pruebas utilizando hooks para crear variables locales y gestionar correctamente las conexiones y los datos de prueba. Hooks como before, after, after each y before each se pueden utilizar para ejecutar código en puntos específicos del ciclo de vida de la prueba. También podemos especificar archivos o utilizar patrones de nombres de pruebas para filtrar las pruebas que queremos ejecutar. Los hooks y el filtrado proporcionan capacidades poderosas para gestionar y ejecutar pruebas de manera eficiente.

¿Alguna pregunta? Esta es una nueva característica. Así que acelera mucho, y es mucho, mucho más rápido. No estoy seguro si otros runners de pruebas, los frameworks de pruebas tienen esta característica. Avísame si conoces esta característica en otros runners de pruebas.

Bien, vamos al número cuatro. Oops. Ve al readme. Bien, esto es más imagina que tenemos que comprobar si un usuario está guardado en la database. Así que si vamos a la fuente, veremos que tenemos algo que se conecta a la database. Estas son todas las funciones simuladas, pero imagina que esto realmente se conecta a la database. Esto cierra la conexión a la database, crea un usuario, autentica, etc. Así que nuestras pruebas se verán así. Creamos la conexión al principio, y luego lo que estamos haciendo en este es que siempre tenemos que crear el usuario al principio, autenticarlo, y luego eliminarlo, porque de lo contrario se solaparán, contaminarán el entorno de prueba, y las pruebas se desordenarán. Así que siempre necesitamos crear, eliminar, etc., etc. Esto se puede hacer de una manera mucho más inteligente utilizando hooks. Está el before, after, after all, before all hooks. Estos son muy útiles para este caso de uso específico. Así que antes de cada prueba, no queremos tener variables globales. Queremos tener variables locales. Así que la conexión, por ejemplo, se crea antes de cada prueba, como al principio, o hay algo antes de cada prueba, etc., etc. Así que podemos reescribir esta prueba moviendo toda la instanciación dentro del hook adecuado. Por ejemplo, imagina al final de la prueba, quiero cerrar la conexión. Al principio, quiero abrir la conexión. Y antes de cada prueba, quiero crear un usuario de prueba. OK, veamos. Te daré cinco minutos, probablemente un poco menos que eso. Simplemente refactorizaremos esta prueba utilizando hooks. Los hooks son, puedes encontrarlos aquí. Before, after, after all, before all. Como en el segundo ejercicio, siempre puedes especificar un archivo, un archivo específico que quieres probar. Por ejemplo, index, quieres ejecutar solo un archivo. Y si quieres ejecutar todos los archivos que terminan con .js, puedes hacerlo. Oh, sí, no es after all. Es solo after each, mi error. Así que sí, puedes especificar. En realidad puedes hacer. Si no especificas nada, ejecutará todas las pruebas. Es un archivo de prueba. Si especificas un archivo, puedes hacer solo una prueba. Ejecutará todas las pruebas. Así que es bastante útil. Así que por ejemplo, si usamos el de antes, como el nombre de la prueba, patrón igual, tenemos autenticar. Como podemos hacer solo este. Oh, me faltó una M. Solo me faltaba una M al final. Como puedes ver, puedes filtrar con cualquier nombre que encuentres aquí. Puedes usarlo. Es muy poderoso. Bien, nos queda solo un minuto. Si necesitas más tiempo, por favor levanta la mano o escribe algo en el chat.

9. Hooks de Prueba y Sintaxis DDD

Short description:

Podemos usar hooks como before, after, beforeEach y afterEach en nuestras pruebas. Además, tenemos la opción de usar la sintaxis DDD, que es simplemente otra forma de escribir pruebas.

Entonces necesitamos usar before, after, y after each, y before each. Esos son los hooks disponibles. Todo está en el readme. Este es el error tipográfico. Sí. Ah, también puedes usar la sintaxis DDD. Puedes cambiar esto con describe e hit en lugar de test. Hacen lo mismo. Es lo mismo. Es solo otra sintaxis. Creo que es la sintaxis del desarrollo guiado por el comportamiento. Sí, hace lo mismo. No cambia nada. Es solo otra forma de, pero prefiero usar solo test. Honestamente, no veo el punto en mis casos de uso.

10. Gestión de Pruebas con Hooks y Palabras Clave

Short description:

Vamos a ver la solución. Inicializamos la conexión a la base de datos utilizando hooks. Re-inicializamos el usuario antes de cada prueba y lo eliminamos después. Tenemos palabras clave como only, to do, y skip para gestionar las pruebas. La palabra clave only es útil para ejecutar pruebas específicas. Podemos saltar o marcar pruebas como to-do. Este test runner es una buena alternativa a otras bibliotecas, reemplazándolas en la mayoría de los proyectos.

Bien, todo bien. ¿Podemos continuar? Entonces, vamos a ver la solución. Así que ponemos la inicialización de la conexión a la database al principio. El hook before each, y luego el after. En el hook after, ponemos un cierre a la conexión de la database. En lugar de tenerlo al final del archivo, que no es ideal, podemos usar estos dos hooks. Antes de cada prueba, reinicializamos el usuario, y después de cada prueba, eliminamos el usuario de la database, así que cada vez nuestro entorno no está contaminado por pruebas anteriores.

Bien. Continuando, tenemos las palabras clave 8.05. Como de costumbre, vamos al readme. Así que hay dos funciones, sum y product. El producto aún no está implementado. Sucede muy a menudo que creamos la función, pero no la implementamos completamente, porque estamos apurados y tenemos que avanzar rápidamente. Y así, si miras el archivo, ahora estamos tratando todas estas pruebas por igual, y ellas serán rechazadas. Porque si no estamos en la prueba, el producto aún no está listo. Se lanzará. Así que necesitamos tener una forma de decirle al test runner, está bien, solo salta esto, porque no está listo. O por ejemplo, estamos trabajando en una prueba, pero aún no está lista. Así que simplemente ponemos, esto me pasa todo el tiempo, así que solo escribo 1 es igual a 1, o 2 es igual a 2, porque todavía es un trabajo en progreso. No lo he terminado. Así que queremos comunicar esto a nuestros colegas. Queremos que otras personas sepan que esto no es un error. Es solo algo que todavía está en progreso. Y por ejemplo, queremos debug una prueba muy específica. Así que por ejemplo, queremos debug solo esta, pero queremos ignorar las demás. Podemos usar las palabras clave. Hay tres palabras clave, que son only, to do, y skip. Estas también son muy útiles, especialmente only. Esa es la palabra clave que usamos todo el tiempo. Asegúrate de que cuando quieras ejecutar solo las pruebas marcadas con only, necesitas usar esta bandera. De lo contrario, será ignorado. Así que vamos a echar un vistazo. Por ejemplo, quiero ejecutar solo esta. Así que solo cambio la entrada a only. Y lo cambio aquí. Pero si ejecuto las pruebas, seguirá fallando, porque será ignorado. Pero si ejecuto test menos una prueba solo, funcionará, porque entonces solo se ejecutará la que está marcada con only. Así que ten cuidado con eso. OK, así que en este ejercicio, queremos saltar esta que todavía es la función donde no está implementada. Así que queremos saltarla. Y luego queremos marcar esta como un to-do, porque todavía estamos trabajando en ella. Y esta, queremos ignorarla, porque nos estamos centrando solo en esta. Así que para esta, creo que dos minutos es más que suficiente. Si necesitas más tiempo, como de costumbre, puedes simplemente preguntarme, y te esperaré.

Cuanto más lo miro, más creo que es una muy buena alternativa a otras bibliotecas. Como en la mayoría de los proyectos, no voy a necesitar una biblioteca, a menos que haga frontend, o a menos que haga algo extremadamente complejo. Pero en su mayor parte, esto reemplaza todo. Como reemplaza a not top, v-test, y todas estas bibliotecas muy pesadas y lentas solo en el núcleo. Obviamente, si no quieres hacer marcado de módulos y características advanced como la interceptación HTTP, necesitas una biblioteca para eso. Pero no es algo que hagas todos los días.

11. Avanzando y Mocks en el Test Runner de Node.js

Short description:

Pasemos al siguiente ejercicio. Tengo una pregunta sobre la palabra clave 'to-do'. Si ejecutas una prueba sin la bandera 'test only', aún se ejecutarán todas las pruebas. Podríamos cambiar este comportamiento en el futuro. Ahora hablemos de los mocks en el Test Runner de Node.js. Incluye mocks y temporizadores incorporados, lo que facilita la simulación de temporizadores. Echemos un vistazo al archivo 'index.js', que contiene la función 'sum'.

OK. ¿Puedo continuar? ¿Algún problema hasta ahora? Asumiré que todo está bien, así que podemos continuar. Oh, sí. Podemos ver la solución. En realidad, podemos saltar el primero. Podemos marcar el segundo como only. Y este, lo marcaremos como to-do, porque la prueba en sí, no está bien hecha. Y este sigue siendo una prueba normal. Entonces, si seguimos adelante, lo siento. Tengo una pregunta sobre to-do. Veo que cuando lo cambio e intento ejecutarlo, la prueba todavía se muestra como aprobada. Me pregunto, ¿es lo esperado? ¿Cuál eres tú? Entonces, si ejecutas una prueba, oh, espera, cambié. Ahora, está corriendo. Espera un segundo. Tengo cero cinco. ¿Prueba solo, quieres decir? Oh, debería ser prueba solo. Sí. Está corriendo, no prueba. Bien, lo entendí. Sí, porque si no ejecutas prueba solo, todavía ejecutará todo. Si ejecutamos prueba solo en la solución, prueba de solución, todavía ejecutará cualquier cosa. Dejará la prueba. Dejará la prueba. Dejará la prueba. Pero todavía ejecutará todo. Todavía ejecutará todo. Todavía ejecutará cualquier cosa. Ignorará el only. Lo tratará como si fuera prueba. Pero si agregamos la bandera en la prueba solo, esto estaba al principio. Solo ejecutará esta. Entonces seguirá. No creo que esto, como proporciona el mejor DEX porque si escribo only, espero que sea el único que se ejecuta. Así que ahora que lo pienso, podríamos cambiar este comportamiento porque es un poco contraintuitivo. Si escribo only, solo, quiero ignorar los demás. Así que sí, gran pregunta. Bien. Vamos al número seis, mocks. Entonces, el Test Runner de Node.js tiene mocks, y esto no es obvio. No sabía al principio que vendría con mocks. Y cuando lo supe, me quedé como, wow, tiene tantas características. Esta, es muy genial. También hay temporizadores que se simulan. Así que no necesitas otra biblioteca para simular temporizadores. Todos sabemos lo difícil y volátil que es simular temporizadores. Así que es genial, pero se introdujo recientemente, creo que hace un par de meses. Echemos un vistazo al archivo index.js. Solo hay una función, sum. Vale. Muy estándar, las que hemos visto antes en el otro ejercicio.

12. Uso del Módulo Mock para Espiar Funciones

Short description:

Con el módulo mock, podemos verificar cuántas veces se llama a una función y ver el mecanismo interno. Podemos importar el módulo mock y las funciones mock. La documentación proporciona más detalles. Al usar la propiedad mock.calls.length, podemos verificar el número de veces que se ha llamado a una función. También podemos inspeccionar los argumentos y el resultado de la función. Esto es útil para funciones complejas y cuando se pasan callbacks.

Entonces, con el módulo mock, ¿es posible verificar cuántas veces se llama a una función, cuántas veces, cuál es el resultado? Y podemos ver todo el mecanismo interno que está sucediendo dentro de la función. Es muy genial.

Entonces, echemos un vistazo. Así que podemos importar el módulo mock del node test. Y podemos hacer mock a la función. También hay otras cosas que pueden ser objeto de mock. Clases, getters, setters, muchas cosas, objetos. Pero para este caso de uso, solo haremos mock a la función. Les aconsejo que echen un vistazo a la documentation. Esto es genial.

Entonces, podemos espiar. Esto crea un espía. Esto nos permite ver cómo se ha llamado a una función, luego cuál fue el resultado. Si lanzó un error. Veamos. Entonces, si yo, en realidad, les daré dos minutos para este. Podemos simplemente, creo que para este, necesitan la documentation. Porque, probablemente, está documentado aquí, creo. Sí, es un poco más temprano. No, entra en tipos. Entonces sí, les daré un par de minutos. Les enlazaré a la documentation sobre esto y les mostraré. Así que tenemos Node.js. Enlazaré en el chat.

Bueno, ¿dónde está el chat? Así que aquí está la documentation sobre mock. En realidad no es demasiado difícil. Así que puedes hacer algo como mock. R-E, agujeros. longitud. Y Sí, podemos hacer mock calls length. Y esto debería imprimir cero, ya que nunca se ha llamado. Luego podemos hacer mock sum, así, a tres. Y luego veremos que este ha aumentado a uno. De hecho, hagámoslo. Hagámoslo. No, no son llamadas. Es mock.calls. Bien, este es el correcto. Bueno, sí. Así que al principio era cero. Ahora que hemos llamado a la función, el contador ha aumentado. También podemos profundizar en, verificar los argumentos. Así que por ejemplo, hacemos console.log holes zero. Podemos ver que los argumentos eran uno, dos, tres. Es un argumento. El primer argumento es este. Bueno, y luego podemos imprimir el resultado. El resultado es seis. Así que esto es muy útil para funciones que son bastante complejas. Puedes espiarlas, o cuando tienes que pasar una función, un callback a algo, puedes ver cómo se llama, qué argumento recibe.

13. Reporteros personalizados e Iterables asíncronos

Short description:

Podemos verificar la longitud, los argumentos de la llamada y los resultados. Simular objetos anidados y crear objetos con funciones envueltas dentro del mock son características útiles. El sitio web de Node.js proporciona ejemplos y más. El reportero es la salida de la tarea, con opciones como spec, dot, YAML y JUnit. JUnit es compatible y parece ser el más popular. Podemos crear reporteros personalizados personalizando el archivo de reportero de índice. Los iterables asíncronos son generadores que producen múltiples resultados.

Entonces, muy, muy útil. Podemos ver la solución aquí. Por ejemplo, podemos verificar la longitud, revisar la primera llamada, qué argumento recibió. ¿Cuál fue el resultado, si fue un error? Y si ejecutamos node minus status, vemos que todo funciona bien. Puedes simular objetos anidados. Puedes crear un objeto envolviendo una función dentro del mock. Esto es muy útil. Y en el sitio web de Node.js, hay muchos ejemplos y cosas que puedes hacer.

Reportero, entonces esto. Vamos al número siete. Entonces, el reportero es la salida de la tarea. Entonces, cuando ejecutas node minus status, tienes un ejemplo. Esta es la salida. Entonces, esto se llama spec. Es legible para los humanos. No está destinado a las máquinas. Y podemos probarlos. Entonces, podemos simplemente copiar y pegar esto e intentar cambiar el reportero. Por ejemplo, el punto. Y verás que solo se imprimen puntos. Y si una prueba falla, será una X. Podemos hacer eso. Y produce esta salida YAML muy detallada y legible para la máquina. Esto es un YAML, por lo que se puede analizar. Y es muy útil para CI. Es algo que otras máquinas quieren analizar. Y luego tenemos JUnit. Y sí, es una salida XML. ¿Cuántos de ustedes usan JUnit o YAML o TAP? Como si usas JUnit, levanta la mano. ¿No JUnit? Porque en la conferencia, cuando di mi charla, como que la gente realmente me preguntó si era compatible. Y yo no sabía que lo era. Entonces pensé, y en realidad, es compatible. Entonces JUnit es compatible. Y parece que probablemente es el más popular. Entonces ahora crearemos nuestro reportero personalizado. Entonces, si queremos crear un reportero personalizado, podemos hacerlo. Entonces, vamos a este archivo, que está dentro de la prueba, reportero, e índice de reportero. Entonces, personalicémoslo para que si es un éxito, imprima este emoji. Si falla, imprime este error. Source es un iterable asíncrono. ¿Conoces los iterables asíncronos? ¿Alguna vez los has usado? Oh, espera, ¿dónde está el chat? Ese es el chat. Bueno, si no sabes qué es un iterable asíncrono, te lo mostraré. Entonces podemos hacer for await event of source. Esta es una función generadora. Esta función es un generador. Y lo editaremos. Entonces la diferencia entre una función normal y un generador es que el generador producirá un resultado en lugar de devolver. Entonces, producirá múltiples resultados en lugar de solo uno. Entonces, esta fuente es un iterable asíncrono.

14. Personalización de la salida de prueba y soporte para TypeScript

Short description:

Podemos personalizar la salida del ejecutor de pruebas mediante el filtrado y la creación de nuestro propio reportero de pruebas. Utilizando tipos de eventos, como test.pass y test.fail, podemos producir diferentes emojis o mensajes. También podemos ejecutar un informe personalizado para ver la salida. Además, el ejecutor de pruebas admite TypeScript, pero requiere el TSX u otros transpiladores como TSNode o SWC. Node.js no conoce nativamente TypeScript y necesita asistencia para transpilar.

Y lo iteraremos con la palabra clave await. Entonces, si hacemos console.log event. Oh sí, se está quejando porque no está produciendo inmediatamente. Interesante. Entonces necesitamos ejecutar esto con nuestro reportero de pruebas. Puedes hacerlo con esta opción aquí. Bueno, este es el evento que recibe. Estos son todos los eventos que está recibiendo. Entonces, el ejecutor de pruebas está produciendo todos estos. Ahora podemos filtrarlos y crear nuestro propio reportero de pruebas. Entonces, por ejemplo, hacemos un switch en event.type. Eso es este aquí. Entonces, en caso de que sea test.pass, producimos esa imagen de aprobado. Y breve. Bueno, en caso de que sea test.fail, producimos el emoji de fallo. Eso también es start. Si queremos comprobar en start, hacemos en start. Producimos el start. Bueno, solo un ejemplo. Hay otros tipos de eventos. Entonces, hay como diagnóstico, útil. Y reset. Así que ejecutemos nuestro informe personalizado. Y podemos ver que la salida fue started, started. Y probablemente necesitamos agregar una línea de separación. Sí. Así que cada vez que se inicia una prueba, se inicia. Sí. Esto es útil. Quieres personalizar algo en la salida de la prueba. De lo contrario, si no pones nada, usará esta línea de separación. Break es la opción predeterminada. Y entonces tenemos path. ¿Preguntas? No hay preguntas.

Bueno, entonces la solución aquí, puedes ver lo mismo. Vamos. Prueba número A. TypeScript. Creo que esto es lo que todos estaban esperando. ¿El ejecutor de pruebas admite TypeScript? Sí. Veamos cómo. Entonces, vamos al readme. Necesitamos escribir npm install. Porque necesitamos instalar el TSX, que es el ejecutor de TypeScript. Pero también puedes usar TSNode o no sé si puedes usar SWC, que es otro transpilador. Bueno, hemos descargado TSX. Pero si intentamos ejecutarlo así, node menos, menos test, y tratamos de ejecutar un archivo con extensión dtf, dará un error. Porque dice que no hay extensión de archivo. Node.js no conoce TypeScript por sí mismo. Necesita a alguien que le ayude a transpilar.

15. Uso de TSX como cargador en Node.js

Short description:

Aprovecharemos TSX como un cargador en Node.js. Hay dos cargadores predeterminados en Node.js: ESM para el tipo de módulo y common.js para el tipo common.js. Con TypeScript, usamos el cargador TSX. Esta característica te da la flexibilidad de elegir qué transpilador usar. Es una característica increíble. Solo agrega import TSX para ejecutar archivos TS. Si tienes alguna pregunta, no dudes en preguntar.

Así que aprovecharemos TSX con la bandera menos, menos import. Así que esto es algo nuevo. Porque antes tenía que ser como node menos, menos load TSX. Pero esto ya no funciona. Sí, no funcionará. Así que ahora necesitas usar TSX. Así que si escribimos node import, igual a TSX. Así que import en realidad le dice a node que use TSX como un cargador.

Así que ahora hay dos cargadores predeterminados en node. Así que hay un cargador que es el que. Así que ya sabes el package.json. Sabes por qué tenemos que decirle qué tipo queremos usar. Si usamos el tipo de módulo, entonces podemos usar esta sintaxis de JavaScript aquí con export e import. Si ponemos common.js aquí, tendremos que usar la sintaxis como require y module.export. Porque estos son dos cargadores diferentes. Así que cuando es de tipo módulo, usamos el cargador ESM. Cuando es common.js, usamos el cargador common.js. Con TypeScript, necesitamos decirle que use TSX como un cargador. TSX y luego hacemos la prueba. Todos, todo se ejecuta con TS y funciona. Y esto también se aplica a la ejecución de TypeScript en Node.js. Puedes hacerlo con node menos menos import TSX o TSNode o lo que quieras usar. Y puedes hacerlo. Y creo que esto es genial en lugar de renderizar el compilador o transpilador de TypeScript como otros tiempos de ejecución. Creo que es bueno darte la flexibilidad de elegir qué transpilador quieres usar. Así que creo que esta es una característica increíble.

Echemos un vistazo a los paquetes y puedes ver aquí. Sí, solo necesitamos agregar import TSX y ejecutar archivos TS. Si tienes alguna pregunta sobre esto, avísame y podemos continuar. Como cómo usar TypeScript en Node, lo que sea. ¿No hay preguntas? Levanta el pulgar si todo está claro hasta ahora. Si no tienes ningún problema o todavía estás vivo y en funcionamiento. Solo veo un pulgar arriba. No diría que todo está claro, pero es interesante. Sí, por favor, por favor, por favor. Es más como nueva información para mí. Es mucha información. Es como nueva información, así que tendría que averiguar más detalles más tarde. Sí, si tienes una pregunta sobre eso. Tenemos tiempo. Así que esta es la mejor oportunidad para hablar con alguien que trabaja en Node.js en sí. Eso puede ayudarte a entender lo que quizás no entiendas. Así que usa este tiempo para hacer cualquier pregunta. Responderé con gusto. Gracias. No realmente. Quiero decir, la mayoría de las cosas están claras. Pero solo para tener todo definido la primera vez. Oh, sí. Sí, creo que es mucha información.

16. Cobertura de Pruebas e Historia del Código

Short description:

Ahora puedes ejecutar la cobertura de pruebas en Node.js sin necesidad de ninguna otra biblioteca. Usa la bandera --experimental-test-coverage para mostrar qué líneas están cubiertas y cuáles no. Para este ejercicio, apunta a un 100% de cobertura añadiendo pruebas para cubrir las líneas no cubiertas. Vamos a tomar unos minutos para discutir la historia de las herramientas de cobertura de código en el ecosistema de Node.js. Anteriormente, Istanbul era la herramienta de cobertura de código más popular, pero tenía limitaciones en precisión y rendimiento. Ahora, Node.js utiliza la cobertura de código V8, que es más precisa y rápida. El motor de JavaScript en sí determina la cobertura de código de tus pruebas. C8 es una biblioteca que proporciona la misma funcionalidad utilizando la cobertura V8.

Pero si estás acostumbrado a otras bibliotecas de pruebas, es muy similar. Nada loco. Hay algunas partes que son complicadas y únicas para Node.js.

¿Alguien más tiene preguntas o quiere volver a alguna de estas? O podemos avanzar. Vale, y avanzamos. Vamos al ejercicio 09, cobertura. Hasta ahora, necesitabas una biblioteca para hacer la cobertura de pruebas. Bueno, ya no la necesitas. No necesitas ninguna otra biblioteca. Así que podemos ejecutar la cobertura de pruebas con esta bandera menos menos experimental test coverage. Así que la bandera todavía es experimental. Así que no es 100% estable. Pero mira esto. Mostrará qué líneas están cubiertas, qué líneas no están cubiertas. Así que es muy útil. Como, esto se usa en cada proyecto, y es importante. Así que para este ejercicio, me gustaría que hicieras la cobertura al 100%. Así que solo necesitas añadir algunas pruebas dentro de este archivo. Para hacer la cobertura al 100%. Así que podemos ver aquí qué líneas no están cubiertas. Y luego tenemos la prueba para cubrir esas líneas. Y mientras haces esto, hablaré un poco sobre la historia de las herramientas de cobertura de código en Node.js ecosystem. La más popular, hace unos años. Era Istanbul. Déjame comprobar la hora. Así que te daré cinco minutos. Es muy fácil. Así que hasta hace unos años, solo estaba Istanbul, que era la función más popular para la cobertura de código. ¿Cómo funcionaba? Así que pasaría por tu código fuente. Y en runtime, inyectaría algunos contadores. Así que cuando leía los archivos, leía el contenido del archivo, añadía algunos contadores, y luego ejecutaba el archivo. Así que si los contadores se incrementaban, significa que tu flujo realmente entró en esa función o objeto. Así que aumentaría el contador. Y así es como comprobaba, OK, si pongo 100 contadores y solo 99 devuelven, eso significa que tu prueba cubrió solo el 99% del código. Y luego, de esa manera, lo haría, estoy haciendo una simplificación, pero así es como funciona. Esto no es preciso. Y también es malo en términos de performance, porque está cambiando el código que estás ejecutando. Así que lo que pasó es que V8, que es el motor de JavaScript dentro de Node.js, dentro de Chrome, es probablemente uno de los, también está dentro de Dino. Así que es el motor de JavaScript, lo que ejecuta JavaScript. Y Node.js es un componente. Es como un complemento de V8. Así que V8, cuando ejecuta JavaScript, ahora ofrece la funcionalidad de cobertura de código. Así que Node.js utiliza la cobertura de código V8, que es la más precisa. Y así es como exportamos esa cobertura a través de la API experimental coverage. Y así es como obtienes la cobertura de pruebas. Así que es el motor de JavaScript en sí el que te dice cuál es la cobertura de código de tus pruebas. Y creo que es muy rápido, muy preciso. Y es mucho mejor que lo que había antes. Si usas la biblioteca C8, hace lo mismo. Utiliza la cobertura V8.

17. Cobertura de Código y C8

Short description:

Solo necesitas agregar una prueba para cada función para completar la cobertura de código. Es bastante sencillo, esta herramienta de cobertura. No ofrece muchas características como otras coberturas de código, como puedes establecer el 100% como C8.

Por eso se llama C8. Pero es la cobertura de V8. OK, así que te daré un par de minutos más para completar la cobertura de pruebas. Solo necesitas agregar una prueba para cada función para completar la cobertura de código. Y luego vuelves a ejecutar la cobertura experimental. Y te sugiero que lo uses en tu proyecto. Aún es experimental, pero creo que es genial. Y recibir comentarios sería muy, muy apreciado. Es bastante sencillo, esta herramienta de cobertura. No ofrece muchas características como otras coberturas de código, como puedes establecer el 100% como C8. Así que es un poco más rústico de alguna manera.

18. Observación y Pruebas con el Node.js Test Runner

Short description:

Vamos a Google y añadimos un tiempo para observar. El Node.js test runner ahora incluye la funcionalidad de nodemon, eliminando la necesidad de una biblioteca externa. Esta característica te permite observar tu código fuente y reinicia automáticamente cuando se realizan cambios. Funciona tanto para pruebas como para archivos reales. Puedes observar archivos individuales, carpetas enteras o varias carpetas. Esta es una característica experimental, pero muy recomendada. Además, recomiendo echar un vistazo a Biome, un nuevo y más rápido Formateador y Linter que reemplaza a Prettier con solo un archivo de configuración.

OK, vamos a Google. Añade un tiempo para observar. Este es el ejercicio. Así que entraremos, oh, por cierto, como viste, todo es de código abierto. También, mis diapositivas están abiertas. Así que puedes volver más tarde y entenderlo después. Así que si pierdes algo, puedes verlo más tarde. Esto será grabado para que no pierdas nada.

OK, así que si continuamos con la prueba, podemos, oh, no, esto no es una prueba. Puedes ver el índice de pruebas test.js. Puedes ver que hemos comentado cada parte. Ahora, si hacemos norma menos menos prueba menos menos observar espacio. OK, así que si en el pasado estabas usando nodemon o nodemon, como quieras llamarlo, ahora está integrado en Node.js. Así que ya no necesitas una biblioteca externa. Esto básicamente observa tu código fuente a medida que lo cambias. Esto también funciona no solo para pruebas, sino para archivos reales. Así que si tengo, como, puedo hacer como menos menos observar fuente index.js, puedo hacerlo. Así que cuando cambio index.js, se reiniciará. Así que ves, cada vez que parpadea, se reinicia. Cancelaré eso. Imprime completo. Y esto también funciona para pruebas. Así que puedes hacer Node.js para pruebas. Esto es útil si estás trabajando en la prueba. Así que a medida que eliminamos los comentarios, podemos ver que elimino los comentarios, y se ejecuta, y pasa. Elimino el comentario. Ejecuta el segundo. Y a medida que elimino el comentario, ejecutará el tercero. Sí, esto es muy útil. También puedes observar una carpeta entera. Puedes observar varias carpetas. Así que imagina que estás trabajando en el código fuente y las pruebas. Así que observas tanto la carpeta de origen como la carpeta de pruebas. Y cuando cambias cosas, te dirá automáticamente si arreglaste la prueba o no. Así que muy útil. Solo para que sepas, esta también es una gran característica. Todavía es experimental. Así que te aconsejo que definitivamente lo uses. Finalmente, solo una última palabra que quiero decir sobre Biome. Si no has comprobado Biome, definitivamente deberías hacerlo. Es el nuevo Formateador, Linter disponible. Como es un reemplazo para Prettier. Y esto es mucho, mucho más rápido, y mucho más rápido. Todo en uno y sin plugins, solo un archivo de configuración. Eso es. Todo está aquí. Así que te sugiero que revises Biome. Muy bien, eso fue todo. Así que para los ejercicios, puedes terminarlos más tarde. No te preocupes.

19. Resumen de Características y Sharding

Short description:

Para ejecutar pruebas específicas, puedes utilizar patrones de nombre de prueba o especificar carpetas o extensiones de archivo. La biblioteca de aserciones admite comprobaciones negativas y positivas. Las pruebas paralelas se pueden habilitar con la bandera --concurrency o pasarse como argumento. Los hooks before se ejecutan antes de las pruebas, y si fallan, todas las pruebas se cancelan. Las pruebas pueden marcarse como pendientes o saltarse. Es posible hacer mocking utilizando el módulo mock. Se pueden crear reporteros personalizados para verificar la salida de la prueba. TypeScript es compatible, y se puede obtener cobertura con la bandera --experimental-coverage. Se recomienda el Node.js test runner para pruebas de front-end y Node.js. Sharding permite dividir las pruebas en varias máquinas, aumentando la eficiencia. Si tienes un conjunto de pruebas grande, puedes ejecutar diferentes partes en diferentes máquinas. Si tienes alguna pregunta, no dudes en preguntar.

Entonces, hagamos un resumen. Esto es cuando quieres ejecutar la prueba. Si quieres ejecutar un archivo específico o una carpeta específica, puedes hacerlo con el patrón de nombre de prueba o explicitando el nombre de la carpeta o la extensión del archivo. Esta es la biblioteca de aserciones. Y también tiene la comprobación negativa y la comprobación positiva. Puedes usar pruebas paralelas con el flag --concurrency. Flag de concurrencia de prueba, como vimos. Pero también puedes pasarlo como argumento de la prueba. Puedes usar el hook before. Lo interesante es que si el hook before falla, entonces todas las pruebas serán ignoradas, serán canceladas. Así que tienes que tener esto en cuenta. Puedes marcar una prueba como pendiente. Así que si la prueba en sí no está completa, también puedes saltar una prueba. Si la funcionalidad no está, o bien imagina que una prueba es falsa, tu funcionalidad aún no está lista, simplemente saltas la prueba. Puedes hacer mocking. Así que puedes usar el módulo mock y puedes, en este caso, hacer un mock de una función. Hace algunos mocks. Así que es muy, muy genial. Puedes crear un reportero personalizado para verificar la salida de los archivos. Pero no estoy revisando el chat. Puedes usar TypeScript con el Node.js test runner. Funciona bien, solo necesitas usar un transpiler. Puedes tener cobertura con el flag experimental coverage. Y puedes observar el código fuente. En resumen, diría que hay muchas características. Si estás haciendo pruebas para front-end o trabajando directamente en Node.js, ya tienes esto, porque estás usando Node. Esto está dentro, no necesitas una nueva biblioteca. Y cuantas menos bibliotecas uses, mejor es, y esto es mucho más rápido que todo. Definitivamente deberías usar el Node.js test runner. Y esto de lo que no he hablado, pero si te has quedado hasta ahora, esta es una característica genial. Puedes hacer sharding de tus pruebas. Significa que si escribes shard one fifth, ejecutará solo una quinta parte de tus pruebas. Entonces te preguntas, ¿por qué quiero ejecutar solo una quinta parte o la mitad de mis pruebas? Porque puedes ejecutar la otra mitad en otra máquina. Así que si tienes un conjunto de pruebas grande que lleva mucho tiempo, lo divides en diferentes máquinas. Así que en la primera, ejecutas una mitad en la máquina A, y la otra mitad en la máquina B. Esto es extremadamente poderoso. Así que definitivamente échale un vistazo. Creo que eso fue todo. Así que si disfrutaste de la presentación, puedes escanear el código QR, puedes encontrarme en Twitter, en cada diapositiva, Satanak, si estoy en GitHub, puedes encontrarme en todas las redes sociales. Todo este contenido está disponible en mi GitHub, así que escanea el código, el QR, y compruébalo allí. ¿Preguntas? Antes de empezar cualquier pregunta o cualquier cosa que quieras... Vale, adelante. Solo una rápida sobre Shards. No estoy seguro de si lo entendí. Entonces, básicamente, ¿toma la primera parte? Y quiero decir, ¿cómo exactamente podemos dividirlos? Imagina que tienes cinco pruebas o 10 pruebas, simplemente tomará una quinta parte. Así que comprobará, contará tus pruebas. Como si tienes 10, solo tomará las dos primeras. Luego, si divides, si haces como sharding dos, quinta parte, tomará la segunda pieza, tres quintos, la tercera pieza, cuatro quintos, y así sucesivamente. Bien, bien. Como si se dividiera en cinco, y luego toma la primera. Así que si seleccionas la segunda, tomará la segunda de cinco. Vale, lo entendí. Me confundí al principio. Sí. Creo que, porque tienes que pensar, quiero dividir mi prueba en cinco partes, pero luego quiero ejecutar solo una quinta parte de todas las cinco. Vale, entonces lo divides por cinco, luego tomas el primer quinto. Muchas gracias. Bien, eso fue todo. Así que muchas gracias por escuchar, y házmelo saber en las redes sociales si quieres escribirme allí, si tienes alguna otra pregunta. Gracias.

Watch more workshops on topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
React Advanced Conference 2022React Advanced Conference 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Featured Workshop
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!