Qué hay de nuevo en el Node.js Test Runner y por qué es revolucionario

Hola a todos. Hoy vamos a hablar sobre el Node.js Test Runner. Así que primero que nada, me voy a presentar. Mi nombre es Luca Santos. Soy uno de los ingenieros de software senior en OpenVault hoy en día. Vivo en Suecia. Soy originario de Brasil. Y puedes contactarme en cualquiera de mis redes sociales. Básicamente, están las que están en la parte inferior. Twitter.elsantos.dev, Instagram.elsantos.dev. Ya sabes, entiendes la idea. Luca es un nombre muy común en Brasil. Así que básicamente, tuve que elegir DNS sobre Nix en las redes sociales. Así que solo coloca el nombre de la red social seguido de .elsantos.dev. O si tienes dudas sobre alguna red social en la que quieras hablar conmigo, solo .elsantos.dev te llevará a mi página principal donde está todo. ¿De acuerdo? Estoy totalmente abierto a hablar de cualquier cosa. Así que contáctame y será muy agradable.

A continuación, compartiré mi objetivo en esta charla contigo. ¿Cuál es el objetivo que tengo con esta charla? Es hacer que dejes de usar Jest al final. Así de simple. No odio Jest. De hecho, lo uso mucho. Pero he tenido mi parte justa de problemas. Y creo que es hora de seguir adelante, ¿verdad? Creo que es hora de que necesitamos algo nuevo, algo mejor. Jest es muy antiguo, ¿verdad? Es muy bueno, pero el tiempo ha pasado, ¿verdad?

Así que voy a hacer esto. Te voy a presentar algo que posiblemente sea mejor. Pero ¿por qué posiblemente mejor? Bueno, porque el Node.js test runner todavía se está mejorando activamente. Así que hay muchas cosas que están sucediendo. Hay muchas cosas que ya tenemos, pero aún faltan muchas cosas. Así que puedes ayudar si quieres, ¿de acuerdo?

Pero primero, ¿qué es malo en el entorno actual? ¿Por qué necesitamos otro test runner? ¿No es suficiente lo que tenemos hoy? Básicamente, lo primero es que son demasiado difíciles de configurar, especialmente para TypeScript. Y hacen muchas cosas. Configurar Jest es un dolor. Es un archivo de configuración muy grande. Hacen muchas cosas. Hacen transformaciones, hacen análisis, hacen movimientos, hacen aserciones, tienen cobertura. Es simplemente demasiado. Y esto los hace lentos, ¿verdad? Porque, bueno, es demasiado. Y luego tienes un concepto que llaman yall, que básicamente es otra biblioteca más en tu proyecto. Porque los runners, en mi opinión, deberían ser una parte de tu entorno de ejecución. No deberías poder instalar, no deberías instalar otra biblioteca para tener un runner. Y recuerda, cada otra biblioteca, cada paquete que se instala en tu proyecto es un code que no mantienes, pero en el que aún dependes, ¿verdad? Así que si algo sucede, pagarás el precio. Y los test runners parecen no querer interoperar entre sí. Se aseguran de que solo puedas usarlos a ellos y a nada más. Así que es muy difícil cambiar de uno a otro. Son cosas completamente diferentes. La mayoría de ellos son bastante dogmáticos. Así que son o muy extensibles o no extensibles en absoluto.

No hay un punto intermedio o algo que puedas extender, o si no quieres extender. Básicamente, es difícil, ya sabes, hacer lo que quieres a menos que tengas algo súper extensible pero a la vez súper difícil de usar como Jest o algo que no sea extensible en absoluto. Si quieres TypeScript, como TypeScript es el némesis de todos los test runners porque lo arruinan por completo. Y si quieres TypeScript, puedes hacer un test runner nativo de TypeScript, que no hay muchos hoy en día, o puedes tener otra biblioteca encima de un proyecto que necesitas instalar para poder ejecutar esto, ¿verdad, completamente?

Y hay tantos de ellos, test runners en Spawnlight, RATS, hay muchos de ellos. Y básicamente es un gran bloat porque no agregan muchas cosas al ecosistema. No interoperan entre sí. Básicamente, son lo mismo con pequeñas mejoras de uno a otro. Pero luego entra en escena el test runner de Node.js. El test runner de Node.js no es tan nuevo. Fue agregado por Colin el 8 de abril de 2022. Y esta fue la versión inicial, como la CLI. Y luego uno de mis antiguos colegas en Microsoft, agregó un analizador TAP. TAP significa test anything protocol. Hablaremos de eso un poco más tarde. Pero te permitía interoperar el test runner con otros test runners, otros procesadores de pruebas en realidad. Luego se estabilizó rápidamente. Aproximadamente cuatro meses después, se hizo estable en Node 20. Así que puedes usarlo en Node 20 y es estable para producción. Puedes usarlo normalmente y libremente.

Pero, ¿por qué es diferente de los demás y por qué lo recomiendo tanto? En primer lugar, es integrado, sin YL, ¿verdad? Así que no es otra biblioteca encima de un proyecto. Es bastante rápido, muy rápido, para ser honesto. Y no necesitas configurar nada. En realidad, no hay rituales que necesites hacer para configurarlo. Funciona perfectamente en Node.js. Puedes usar aserciones nativas si quieres, pero reconozco que la biblioteca de aserciones nativas no es tan increíble como otras, pero puedes cambiar las bibliotecas a cualquier otra biblioteca de aserciones. Genera el protocolo TAP, por lo que es fácil de integrar. Acepta otros reporteros de pruebas también. Siempre puedes usar las características más actualizadas de Node.js porque siempre está actualizado con las características de Node.js. Lo mejor de todo es que tiene consistencia en todo tu proyecto.

Entonces tienes miles de proyectos, todos van a estar usando el mismo test runner y el mismo test runner de Node.js que está construyendo el tiempo de ejecución, ¿verdad? Entonces te vas a basar en el propio tiempo de ejecución. No hay polyfills que necesites hacer, como cosas de Babel y blah, blah, blah. Y tiene soporte experimental para la cobertura de código y por ahora, se está volviendo estable a lo largo de los años y también otros reporteros. Y admite TypeScript de forma nativa. Es muy fácil hacer que se ejecute como ejecutarías TypeScript en Node.js normalmente, ¿verdad? Así que empecemos. Permíteme mostrarte cómo funciona. Primero, declaramos la función que queremos probar y luego creamos nuestra prueba, ¿verdad? Así que vamos a desglosar eso un poco. Primero escribimos la prueba. Simplemente importamos nuestras bibliotecas, importamos el describe y it. Puedes usarlo directamente con una prueba. Prefiero usarlo así porque creo que es mucho más fácil de leer. Luego importamos la función de aserción, la biblioteca de aserciones. Es la misma que usamos en otras bibliotecas. Es un poco diferente, no es tan fácil de leer pero me gusta usar la nativa porque es nativa. Luego importamos nuestra función que queremos probar y luego la prueba es básicamente la misma prueba que escribiríamos en cualquier otro test runner. Así que describimos el nombre del conjunto de pruebas y luego it y luego la prueba que quieres ejecutar y luego tienes assert y eso es básicamente todo. Si no quieres usar describe o cualquier otra cosa puedes importarlo directamente como prueba desde no test. Y eso es lo que te dije, es un poco más verboso pero funciona igual. Y las bibliotecas de aserciones son manejadas por el módulo de la biblioteca de aserciones, que está integrado pero reconozco que esta no es realmente la mejor. Probablemente me gustaría decir que deberías usarla porque es nativa, pero no es la mejor biblioteca integrada allí. Así que puedes usar cualquier otra que quieras como Chai u otra cosa que quieras usar. Básicamente solo la importas, lo único que debes asegurarte es que la biblioteca de aserciones lance cuando haya un error. Cuando hay un error, lanza y listo. Y como hice aquí, simplemente importé Chai desde, expect de Chai y luego funciona normalmente. Lo importante es que la biblioteca de aserciones está completamente desvinculada del runner. Así que puedes ejecutar lo que quieras, es lo suficientemente extensible para hacerlo. Y cuando ejecutas, básicamente estás ejecutando node --test y el nombre de tu archivo de prueba. Node simplemente agrega el comando de prueba al comando node y luego ejecuta tus archivos de prueba. Te dará una salida en formato TAP.

En primer lugar, puedes ver todo, como todos tus conjuntos de pruebas, y luego puedes ver las pruebas canceladas, las pruebas omitidas, también es una característica compatible. Puedes ver las pruebas por hacer, también es una característica compatible.

Y luego tenemos las simulaciones. Las simulaciones son una de las mejores y más importantes características de una prueba, en realidad. Para mí, es la mejor característica de Jest, las simulaciones. Pero Node también las tiene. Node admite la simulación de algunas de las estructuras integradas. Por ejemplo, mock Fn es similar a Jest Fn, como simulaciones y funciones, solo una función espía. También simula getters, setters, y actualmente también puede simular métodos, ¿verdad?

Pero también hay otras dos estructuras complejas que te voy a mostrar. La primera de esas estructuras es la fecha, en realidad, en realidad los temporizadores. Esto fue agregado por un buen amigo mío, Eric. Básicamente, simula cosas como setTimeout, setInterval y cosas así. Entonces, básicamente, lo que necesitas hacer es crear tu prueba, y luego creamos una función, que es una función espía, y luego habilitamos la funcionalidad de simulación de temporizadores, diciendo qué biblioteca, qué API queremos simular. Entonces, básicamente, setTimeout es el que queremos simular. Y luego simplemente establecemos un tiempo de espera de, por ejemplo, 99999 algo. Y luego vamos a afirmar que el temporizador aún no se ha llamado porque el temporizador no ha sido ejecutado. Entonces tenemos que hacer que ese temporizador se ejecute, y luego podemos afirmar nuevamente y decir, eh, ahora se ha llamado este tiempo. Y podemos restablecer el temporizador a su estado original.

También puedes importar los temporizadores simulados directamente desde el directorio de pruebas de Node. No necesitas importarlo como en el contexto como lo estamos usando aquí, como context.mocks. Puedes importarlo directamente desde la prueba. También funciona, básicamente como lo estamos haciendo aquí. Y la siguiente estructura compleja fue agregada por su servidor, y son las fechas. Esta es una característica en la que personalmente he trabajado y que se basa en estructuras anteriores como setTimeout e setInterval, te permite simular el objeto de fecha. Entonces, simular fechas en Node es, lo único que tenemos que hacer diferente es habilitar las simulaciones para usar la API de fecha. Y luego iniciamos la simulación. Comenzará con la época de Unix, es decir, el 1 de enero de 1970. Y luego podemos avanzar en la simulación, y luego podemos afirmar que la nueva fecha será esa fecha más 9999 milisegundos. Es algo muy útil si quieres lidiar con mensajes y cosas así.

Así que lo usamos mucho. Y la cobertura de código es el siguiente paso para las compatibilidades de las que quiero hablarte. El test runner de Node.js tiene soporte nativo. Simplemente pasas la bandera, que es experimental test coverage. Va a utilizar la función de cobertura incorporada de V8 para darte una salida como esta. Te dará el comando que vamos a ejecutar y estas serán las pruebas que se van a ejecutar. Luego tenemos la salida TAP habitual que tenemos en el lateral, y luego tenemos el inicio del informe de cobertura. Como puedes ver, en el resultado de la cobertura, hay dos líneas que no fueron cubiertas, que son las que lanzamos aquí en nuestra función. Así que funciona como se esperaba, ¿verdad? También puedes cambiar los reporteros de cobertura. Puedes usar diferentes reporteros y/o generar informes directamente en archivos, utilizando el test reporter o el test reporter destination. Actualmente, el test runner nativo admite estos reporteros. Puedes usar los reporteros spec.tap, lcol y JUnit también, de forma nativa, solo tienes que ponerlos en el test reporter, igual y el nombre del reportero.

Pero ahora hablemos de TypeScript, que es lo que más me gusta. Un poco de información adicional aquí, pero no sé si sabes todo esto, pero Node ya te permite compilar TypeScript sobre la marcha utilizando importers, ¿verdad? Anteriormente, los importers se llamaban loaders, y son funciones que se ejecutan antes de que se cargue un módulo y también se pueden utilizar para transformar un módulo antes de importarlo. Babel tiene loaders, Jest tiene loaders, muchas otras herramientas que utilizamos tienen loaders porque puedes importar el módulo y luego va a cambiar el archivo en el que estás y luego va a ejecutar el archivo en el que estás, ¿verdad? Esto significa que también puedes ejecutar TypeScript porque simplemente puedes importar un archivo TypeScript y luego convertirlo a JavaScript, ¿verdad? Y los importers comunes que tenemos hoy en día son ts-node, ts-sex y ts-build. También puedes crear el tuyo propio si quieres, si no quieres utilizar ninguna biblioteca externa. Me gusta ts-sex, creo que es uno de los mejores que hay. Y para el soporte de TypeScript, solo he cambiado el archivo que teníamos antes. Solo he añadido algunos tipos y luego podemos ejecutarlo con import ts-sex y básicamente el archivo ts index.ts, y luego boom, magia, ¿verdad? Pero, ¿qué pasa si te dijera que en realidad puedes usar esto para ejecutar el test runner? Así que el soporte de TypeScript, solo tomamos nuestra extensión de archivo anterior y le añadimos --test. Así que boom, se ejecuta, nada más, como magia. Eso es todo, todo se ejecuta, no hay configuración, nada, solo ejecutamos con cosas nativas, ¿verdad? Y cuando ves esto, como ese archivo de configuración de jazz de 50 líneas que has estado manteniendo durante los últimos cinco años, verás que esto es bastante agradable porque ya no tienes que mantener TypeScript, así que es súper, súper agradable. Y hay otras características compatibles para el test runner de Node, por lo que en realidad puedes abortar pruebas a través de señales de aborto. Puedes saltarte la prueba, como dije, con it skip o it to do para una prueba que aún está por hacer. Puedes marcar una prueba específica que quieres ejecutar, así que con it only, es divertido, súper agradable. Y también tenemos ganchos del ciclo de vida como lo hace Jest con before, after, before each, after each y cosas así. Y también puedes filtrar el patrón de nombre a través de rejects. Ahora puedes hacerlo, creo que Node 21 ha añadido el soporte para globs, así que ahora puedes añadir globs en los nombres de archivo y tienes un modo de observación, que es experimental. Pero el futuro de las pruebas en Node.js, y curiosamente, Colin mismo tiene una lista de lo que quiere para el test runner de Node.js. Lo primero que quería mostrarte es la simulación de módulos. Básicamente, la simulación de módulos también se está implementando en el test runner.

Es un poco diferente de lo que esperaría, pero la idea de que realmente puedas simular todo el módulo y no solo los métodos o archivos y cosas así, puedes simular realmente muchas cosas. Es súper genial. Luego tenemos un mejor filtrado, que es justo lo que acabo de decir. Entonces, básicamente, puedes ejecutar por patrón de nombre de prueba, ahora creo que puedes ejecutar con globs y aún se está mejorando. No es lo mejor, pero lo será en el futuro. Luego también podemos tener más importers, más reporteros y pruebas de snapshot. Las pruebas de snapshot son algo en lo que quería trabajar, pero es una cosa de biblioteca de aserciones. Ok, así que se agregó brevemente durante unas pocas semanas en el runner en el pasado, pero se eliminó debido a algunos problemas de almacenamiento, como problemas de almacenamiento que tuvimos con el runner, y luego se eliminó. Pero realmente quiero agregar esto de nuevo porque las pruebas de snapshot son súper, súper agradables. Luego tenemos soporte de mapas de origen, que básicamente habla por sí mismo, y más, más mocks. Quiero crear, creo que es importante que tengamos mocks para todo, no solo mocks de módulos. Personalmente, quiero trabajar en los mocks de rendimiento. Quiero trabajar en otros mocks que podamos crear a partir de los módulos nativos y las pruebas nativas de Node. Ok, eso es una de las cosas que realmente me gusta. Y al final de esto, espero que tengamos la caída definitiva, supongo. Pero eso es solo una broma. Sé que llevará un tiempo, pero por ahora, podemos seguir usándolo tal como está hoy. Pero ¿puedes participar en esto, verdad? Oh, volvió. Así que puedes participar en esto, ¿verdad? Lo primero es que la documentación siempre es un buen lugar para comenzar. Si quieres saber cosas sobre Test Runner, ve allí, intenta documentar algunas cosas. También puedes contribuir al código, tal vez hacer feliz a Colin con su lista de deseos. No sé. Tal vez seas tú quien le dé este regalo. O simplemente úsalo, brinda comentarios, porque es muy agradable tener a alguien que brinde comentarios sobre los módulos y las APIs y las cosas que realmente están en la línea de producción. Cosas que la gente está usando de verdad, lo que está ahí. Comienza a cambiar tus proyectos a esto, ayuda al crecimiento de la comunidad. No es difícil cambiar una cosa por la otra. En realidad, es bastante simple cambiar de un runner a otro, ¿de acuerdo? Espero haberte convencido. Y muchas gracias por el tiempo que has estado aquí conmigo hoy. Si quieres hablar conmigo, simplemente ve a cualquiera de mis redes sociales. Si quieres ver esta agradable charla, ve a este código QR o a este enlace que estoy dejando aquí. Y espero que te haya gustado. Nos vemos pronto. ♪♪♪