Explorando Node.js Test Runner

Rate this content
Bookmark

La charla "Explorando Node.js Test Runner" profundiza en el concepto de un test runner, arrojando luz sobre su papel esencial dentro del ecosistema de Node.js. Proporciona una visión general de por qué el desarrollo de un test runner para Node.js tomó un tiempo considerable, y presenta una exploración de su funcionamiento interno.

28 min
07 Dec, 2023

AI Generated Video Summary

La charla de hoy presenta el nuevo test runner de Node.js y sus características, incluyendo el filtrado, sub-testing, y reportes. También discute la ejecución y escritura de pruebas en Node.js, así como las características de la biblioteca de pruebas de Node.js. Las ventajas del test runner de Node.js incluyen la capacidad de crear reporteros de pruebas personalizados y usar TypeScript. Sin embargo, hay limitaciones como un pequeño ecosistema y bibliotecas limitadas. Las características próximas incluyen la planificación de pruebas, la ejecución de pruebas más rápida, y la evolución continua. La sesión de preguntas y respuestas cubre temas como la velocidad del test runner, reporteros, sharding, y paralelización.

1. Introducción al Test Runner de Node.js

Short description:

Hoy vamos a hablar sobre la nueva característica de Node.js, el test runner. Un test runner es una herramienta CLI que ejecuta pruebas e integra un reportero para exportar el resultado. Mocha, Cypress y Chai son marcos de pruebas populares construidos sobre Mocha, proporcionando diferentes funcionalidades. Estos componentes permiten realizar pruebas en nuestras aplicaciones.

Hola a todos. Gracias por tenerme hoy. Así que hoy vamos a hablar sobre la nueva característica de Node.js, el test runner. Primero permítanme presentarme. Soy Marco Ippolito. Soy uno de los mantenedores de Node.js, enfocándome principalmente en seguridad. Y trabajo mucho en el ecosistema de código abierto de Node.js.

Entonces, comencemos por las definiciones. ¿Qué es un test runner? El test runner es en realidad la herramienta CLI que ejecuta la prueba e integra un reportero para exportar el resultado de la prueba. Así que recorre tu código fuente y selecciona los archivos de prueba para ejecutar. Veamos un poco de clasificación. Mocha, por ejemplo, es un test runner y marco de pruebas muy popular porque las dos cosas van juntas. Y el test runner siempre incluye el marco de pruebas porque de lo contrario, ¿qué vas a elegir para ejecutar el archivo pero qué más vas a ejecutar? Así que el marco de pruebas proporciona el contenido que está dentro del archivo mientras que el test runner encuentra el archivo para ejecutar. Así que Cypress es otro marco de pruebas popular que se construye sobre Mocha. Así que Mocha se encarga de recorrer el código fuente y encontrar qué archivos quieres ejecutar, y luego Cypress se construye sobre las bibliotecas BDD de Mocha. Mientras que Chai es solo una biblioteca de afirmaciones que también se construye sobre Mocha. Así que tenemos tres componentes principales que nos permiten realizar pruebas en nuestra aplicación.

2. Características del Test Runner de Node.js

Short description:

En el ecosistema de Node.js, existen muchos marcos de pruebas de test runner debido al principio de núcleo mínimo. Node.js prefiere mantener su núcleo mínimo y confiar en los paquetes NPM para características adicionales. Sin embargo, esto ha llevado a un gran ecosistema, dificultando que los nuevos desarrolladores encuentren recursos y aumentando el riesgo de ataques a la cadena de suministro de NPM. Para abordar esto, Node.js introdujo su propio test runner nativo y marco de pruebas, inspirado en Node.tap. El test runner de Node.js proporciona características como filtrado, sub-pruebas e informes.

Bien. Así que ahora hemos hablado mucho sobre las bibliotecas pero ¿qué pasa con Node.js? En los ecosistemas de Node.js hay muchas bibliotecas y quiero, digamos, ver las más populares. Así que tenemos Mocha de la que hablamos, Jest, TAP. Tenemos una gran cantidad de bibliotecas. Y aunque es bueno tener mucha variedad, en realidad es malo para los nuevos desarrolladores que quieren aprender cómo hacer pruebas en Node.js porque hay una cantidad increíble de información y es difícil encontrar una guía y algo para comenzar a testing.

Entonces, ¿por qué hay tantos marcos de pruebas de test runner en el ecosistema de Node.js? Bueno, es porque Node.js siempre sigue el principio de núcleo mínimo y podemos hablar de que esto también está relacionado con todo el ecosistema de JavaScript. Así que Node.js no quiere añadir a su núcleo nada que pueda ser un paquete de NPM. Así que cuando alguien solicita una característica a Node.js lo que decimos es, simplemente crea un paquete. Pero con los años esto ha llevado a un enorme ecosistema y ha deteriorado la experiencia del desarrollador. Así que las personas que querían aprender a usar Node.js lo encontraron muy difícil debido a la gran cantidad de paquetes y también tener demasiados paquetes aumentó la superficie para los ataques a la cadena de suministro de NPM. Y yo soy uno de los miembros del equipo de seguridad de Node.js y hemos estado tratando de disminuir el riesgo de ataques a la cadena de suministro de NPM con el modelo de permisos de Node.js y muchas cosas. Así que tener algo incorporado en el núcleo es un paquete menos, una potencial vulnerabilidad menos.

Bueno, entonces Node.js en realidad solo estaba enviando una biblioteca de afirmaciones. Desde Node 12 no había test runner, no había marco de testing, solo una biblioteca de afirmaciones muy, muy pequeña que no era muy útil. Así que Node.js necesitaba un test runner nativo y un marco de pruebas nativo para que pudieras ejecutar pruebas en Node.js sin instalar ninguna otra dependencia. Así que tomó algún tiempo. Fue marcado como estable en Node 20. Así que desde Node 20 que es el LTS y si no estás usando Node 20 deberías. Puedes usar el test runner de Node.js. Así que sí, tomó algún tiempo. Tomó un par de años hacerlo pero finalmente lo tenemos. Y ahora vamos a explorar algunas de las características. Así que el test runner de Node.js en realidad se inspiró mucho en Node.tap. Node.tap es uno de los, en mi opinión, mejores marcos de pruebas y test runners en Node.js. Fue creado por Isaac, el creador de NPM, por lo que es bastante popular y tomamos una gran inspiración de esta biblioteca y en realidad es uno a uno. Puedes simplemente reemplazar la importación y es lo mismo. Utiliza las mismas funciones. Así que veamos algunas de las características del test runner de Node.js. Así que veremos como el filtrado y cómo ejecutar ciertas pruebas y omitir otras. Hablaremos sobre las sub-pruebas, los informes.

3. Ejecución y Escritura de Pruebas en Node.js

Short description:

Discutiremos la importancia del mocking, el modo watch y la cobertura de código en Node.js. Para ejecutar pruebas, use el comando 'Node --test', que selecciona automáticamente la carpeta de pruebas y ejecuta todas las pruebas de JavaScript. Puede especificar la carpeta y la extensión, y usar la opción '--watch' para observar la carpeta de pruebas o un solo archivo. Escribir pruebas es fácil con la sintaxis estándar y la biblioteca de afirmaciones. Se pueden hacer afirmaciones positivas y negativas utilizando las bibliotecas 'Node test' y 'Node assert'.

Esto es muy importante y el mocking. Y también tenemos el modo watch que si no sabes sobre el modo watch, es una característica experimental muy interesante que tiene Node.js. Y la cobertura de código, que también son características experimentales muy interesantes. Y hablaremos de por qué es muy importante tener una cobertura de código, una biblioteca interna de cobertura de código.

Muy bien. Así que hicimos mucha teoría y como alguien mucho más importante que yo dijo, hablar es barato, muéstrame el código. Así que sí, vamos a hablar de código. Muy bien.

Entonces, ¿cómo ejecutar una prueba? simplemente ejecutas Node dash dash test. Y desde Node 20 puedes hacerlo. Seleccionará automáticamente la carpeta de pruebas dentro de tu aplicación y ejecutará todas las pruebas en archivos JavaScript dentro. También puedes especificar la carpeta que quieres ejecutar y especificar también la extensión si estás usando un archivo CGS, MGS, dependiendo de la versión de JavaScript que estés utilizando. Y también puedes observar la carpeta de pruebas con la opción dash dash watch. Y es muy, es muy, como siempre lo uso. Muy bien. Así que sí, también puedes observar un solo archivo en lugar de una carpeta. Watch sigue siendo experimental. Así que te sugiero que lo uses y proporciones comentarios al proyecto Node.js. Así que si encuentras algunos errores, simplemente abre un problema y esto ayudará a toda la comunidad.

Muy bien. Entonces, ¿cómo escribir una prueba? Es muy fácil. Simplemente creas tu, simplemente tienes la sintaxis estándar y la biblioteca de afirmaciones. Puedes importarla de Node test y Node assert. Y luego puedes afirmar algo muy estándar. Repasaremos la biblioteca de afirmaciones en un momento. Tiene una subcarpeta estricta donde hay estrictos para comprobaciones de igualdad profunda y también comprobaciones no estrictas. Así que hay muchas afirmaciones que puedes hacer. Hay la afirmación positiva. También puedes hacer la afirmación negativa añadiendo un not al principio.

4. Características de la Biblioteca de Pruebas de Node.js

Short description:

La biblioteca de afirmaciones solía soportar pruebas de instantáneas, pero era inestable y se eliminó. Ahora, se están haciendo esfuerzos para traerlo de vuelta. La biblioteca de pruebas de Node.js ofrece una gama de características, incluyendo pruebas sincrónicas y asincrónicas, palabras clave BDD, filtrado, hooks y mocking. También ofrece varios reporteros, como spec, tap y dot.

Muy útil. Una cosa, un dato curioso sobre la biblioteca de afirmaciones, solíamos enviar pruebas de instantáneas testing, pero decidimos eliminarlo porque no era lo suficientemente estable. Así que estamos tratando de traerlo de vuelta porque personalmente me encantan las pruebas de instantáneas testing.

Y también puedes, obviamente, ejecutar una prueba sincrónica con diferentes tipos de nivel. Así que tienes un nivel superior y sub testing. Esto es bastante poderoso en Node.js porque la mayoría de las veces van a ser asincrónicas.

Y también puedes usar las palabras clave BDD como describe e it, hacen lo mismo. Es sólo otra sintaxis para las personas que quieren usar pruebas orientadas al comportamiento testing. La biblioteca de pruebas Node.js también proporciona algunas palabras clave como to do, skip y only. Así que puedes filtrar tu prueba basándote en, puedes escribir, sabes que querrás escribir la prueba más tarde así que la marcas como to do, quieres saltarla porque no está lista todavía, puedes simplemente saltarla. Así que proporciona una completa, completa utilidad para testing.

Obviamente todos los hooks, before, before all, after, after all. Estas son nuestras características estándar que Node.js proporciona de serie, así que no necesitas instalar ninguna otra biblioteca. Puedes filtrar por patrón de nombre. Así que por ejemplo, si quieres escribir sólo la prueba que contiene la palabra foo en la descripción, puedes hacerlo. Así que en este ejemplo, sólo ejecutará foo pero saltará bar, esto es muy útil.

Puedes hacer mocking. Tiene, de serie, la funcionalidad de mocking así que puedes hacer mocking de funciones de objetos, lo que sea, no necesitas bibliotecas como xenon y viene todo de serie.

Sí, puedes elegir tu propio reportero. Así que la mayoría de la gente usa spec, que es el predeterminado. Así es como se ve. Pero también puedes usar tap si te gusta la salida YAML. Personalmente no me gusta YAML, tap, porque es muy verboso, pero puede ser parseado por máquinas. Así que en realidad es bastante bueno para automatizaciones. Y así es como se ve la salida tap. Así que bastante estándar. También tenemos dot como reportero. Así que si estás familiarizado con algo como PHP units, sí, la salida es sólo un punto. Y una X si falla. Aún no lo he usado.

5. Reportero de Pruebas Personalizado y TypeScript en Node.js

Short description:

Puedes crear tu propio reportero de pruebas personalizado utilizando una función. Node.js utiliza la cobertura interna de V8, lo que lo hace poderoso y elimina la necesidad de bibliotecas externas. TypeScript puede ser utilizado en Node.js requiriendo y utilizando el transpilador TSNode o TSX.

No sé por qué alguien debería usarlo, pero siéntete libre de probarlo. Y puedes crear tu propio reportero de pruebas personalizado. Por ejemplo, si la prueba pasó, devuelves un cheque verde y si no, devuelve un error. Y puedes hacer esto creando una función. Y es solo un iterador asíncrono. Así que estoy seguro de que todos ustedes usan iteradores asíncronos todos los días, ¿verdad? ¿No? Así que sí.

Vale. Y ahora hablamos de cobertura. Node.js incluye cobertura. Es experimental. Y es muy útil porque a diferencia de otras bibliotecas, por ejemplo, Estambul, que añaden controles durante la ejecución. Así que toman tu código, añaden pequeños contadores, y comprueban cuántos contadores se han actualizado. Y luego hace alguna lógica para comprobar realmente la cobertura. Esto no es cómo lo hace Node.js. Node.js utiliza la cobertura interna de V8. Así que es muy poderoso. Y si estás utilizando C8 como una biblioteca de cobertura, utiliza los internos de Node.js para hacerlo. Así que puedes tenerlo de serie. No necesitas bibliotecas externas. Está dentro de V8 y Node.js te lo ofrecerá. Y esto es lo que parece la cobertura con el reportero por defecto, que es una especificación. Y tienes para cada archivo las líneas de cobertura, rama, y etcétera. Así que también aquí. Bastante estándar si estás acostumbrado a testing.

Puedes usar TypeScript. Así que hay mucha controversia en esto porque Node.js es el único runtime que no incluye TypeScript de serie. Y hay una razón detrás de esto. Así que siéntete libre de hablar de esto después de la charla. Pero puedes hacerlo bastante fácilmente. Solo necesitas requerir y usar TSNode o TSX, el transpilador de TypeScript que prefieras.

6. Ventajas y Limitaciones del Ejecutor de Pruebas de Node.js

Short description:

Y luego simplemente usas --"require." Y puedes ejecutar pruebas de TypeScript muy fácilmente. La sintaxis cambió bastante recientemente. Antes era un cargador, --"loader." Ahora es -"require." Ha sido una gran actualización. Otra característica importante son los fragmentos. Te permite dividir y ejecutar pruebas en varias máquinas, lo que lo hace ideal para grandes suites de pruebas en CI/CD. Sin embargo, migrar una suite de pruebas existente puede no valer la pena. El ejecutor de pruebas todavía es nuevo, con un pequeño ecosistema, bibliotecas limitadas y APIs. Además, no hay soporte nativo para TypeScript, requiriendo el uso de un transpilador como Node.js, TS Node, o TSX.

Y luego simplemente usas --"require." Y puedes ejecutar pruebas de TypeScript muy fácilmente. La sintaxis cambió bastante recientemente. Antes era un cargador, --"loader." Ahora es -"require." Ha sido una gran actualización.

Y sí, esta es otra característica muy importante. Son fragmentos. Así que si tienes una gran suite de pruebas, puedes dividir la prueba en piezas. Y puedes ejecutar esta prueba en varias máquinas. Esto es algo que se lanzó en Node 21. Así que aún no está en el LTS. Y esto es enorme porque si tienes una gran biblioteca de testing en tu CI CD, puedes ejecutar solo una pequeña pieza en una máquina. O puedes ejecutar solo como la mitad de ella. Básicamente puedes dividirla y elegir qué parte de tu prueba ejecutar. Así que sí, esta es una de las mejores características.

Así que sigamos. ¿Debería migrar mi suite de testing mañana? No. Definitivamente no deberías. Es genial tener algo dentro del runtime en sí. Pero si ya tienes tu suite de pruebas, no tiene sentido poner mucho esfuerzo en migrarla. Pero si estás empezando un proyecto desde cero, entonces es algo que podrías estar interesado en. OK, hablemos de los contras del ejecutor de pruebas, el trabajo que estamos haciendo y cómo lo estamos mejorando. Así que pequeño ecosystem. Acaba de ser lanzado. El LTS fue introducido el mes pasado. Así que es muy nuevo. Y por lo tanto, pequeño ecosystem, no hay bibliotecas, no hay guías. Así que todo es nuevo. No muchas APIs, así que no está completo. No está sobrecargado como algunos otros testing frameworks. Y no hay soporte nativo para TypeScript. Siempre necesitas un transpilador como Node.js, TS Node, o TSX, o lo que sea.

7. Características Próximas y Cobertura de Código

Short description:

Las características próximas incluyen la capacidad de planificar y controlar el número de pruebas, temporizadores negros para una ejecución de pruebas más rápida y una evolución continua con nuevas APIs añadidas diariamente. Otras características como salir en caso de fallo, fianza y esperar fallo para pruebas negativas también son dignas de exploración. Se recomienda la observación y la cobertura de código, ya que son experimentales pero altamente útiles. Manténgase actualizado sobre las nuevas características a través de Twitter y LinkedIn. Por último, la cobertura de código es una característica que debería emocionar a los desarrolladores.

Así que la próxima característica, planificación. Puedes decidir cuántas pruebas quieres ejecutar. Y si no coinciden, te lanza un error. Temporizadores negros. Y de hecho se implementó y se lanzó hace poco tiempo. Así que el ejecutor de pruebas se está ejecutando muy rápido. Está evolucionando muy rápido. Se añaden nuevas APIs cada día. La Community está muy interesada en ello. Así que esperamos que mejore pronto.

Y salir en caso de fallo, fianza. Es una característica genial. De hecho, intenté implementarlo yo mismo, pero fallé debido a las complejidades. Y así que intentaré de nuevo en el futuro implementar las fianzas en caso de fallo. Y la última es en realidad esperar el fallo. Así que pruebas negativas. Así que si en realidad esperamos que una prueba falle en lugar de que una prueba pase. Así que te sugiero que en realidad uses estas características. Si no todas ellas, al menos observar y la cobertura de código, que son muy útiles. Son experimentales. Así que por favor úsalas y proporciona retroalimentación para que podamos mejorarla para todos.

Y eso fue todo. Puedes encontrar todos mis enlaces y trabajo sobre Node.js. Actualizaré sobre las nuevas características en Twitter, LinkedIn. Eso fue todo. Gracias. Realmente, realmente disfruté tu charla. Tantas características nuevas. Y una cosa que siempre me gusta preguntar a las personas que construyen cosas como esta. ¿Qué característica crees que los desarrolladores aún no conocen, pero deberían estar más emocionados por ella? Definitivamente la cobertura de código.

QnA

Preguntas y Respuestas del Test Runner de Node.js

Short description:

Es muy rápido. Es más rápido que cualquier otra biblioteca que estés utilizando. Y es el más preciso porque utiliza internamente V8. Pasemos a las preguntas de la audiencia. La primera es sobre los reporteros. Preguntan por qué no hay un reportero JUnit incorporado. Empezamos con TAP, y nadie en el equipo de mantenedores de Node.js está interesado en JUnit. Otra pregunta es sobre el sharding. El test runner puede shard basado en la fracción de pruebas. Puedes jugar con la fracción dependiendo del número de máquinas. Y finalmente, el test runner de Node.js puede paralelizar pruebas.

Es muy rápido. Es más rápido que cualquier otra biblioteca que estés utilizando. Y es el más preciso porque utiliza internamente V8. Así que sí, definitivamente ese. Estoy realmente emocionado de probarlo. En realidad aún no lo he probado. Así que voy a probarlo. Y también tengo una idea para una charla que quiero dar basada en esto. Quiero agradecerte de antemano.

Muy bien. Pasemos a las preguntas de la audiencia. Tenemos la primera, que es sobre los reporteros. Y preguntan, ¿por qué no hay un reportero JUnit incorporado? Suele ser el caso de uso más común ya que es el formato por defecto para los resultados de pruebas legibles por máquina. Así que eso es porque empezamos con TAP, que fue de donde tomamos inspiration. Y sí, probablemente porque nadie en el equipo de mantenedores de Node.js está interesado en JUnit. Así que aún no lo hemos construido. Pero si hay interés, seguramente lo construiremos. Así que entra en GitHub y hazles saber que quieres reporteros de pruebas JUnit también.

Tengo una pregunta, y esto es algo que también me interesa mucho. Así que gracias, Norbert, por preguntar esto. ¿Cómo funciona el sharding? ¿Puede shard basado en cuánto tiempo se ejecutará la prueba? Porque vi que tenías ese tipo de fracción. Estaba realmente interesado. ¿Cómo se hace esa fracción? ¿Simplemente la haces sobre la marcha, y hace una quinta parte de las pruebas? Sí, en realidad hace una quinta parte de la prueba. Y puedes jugar con la fracción, dependiendo, por ejemplo, si tienes cinco máquinas, entonces divides una quinta parte para cada máquina. Y es muy útil. Eso es realmente genial. Eso es realmente genial. Estoy realmente emocionado de probar eso también. Y luego otra pregunta, y creo que vi un fragmento de código que tenía esto, ¿puede el test runner de Node.js paralelizar pruebas? Y si es así, ¿cómo lo controlas? Sí, puede. Puede paralelizar pruebas con el...

Preguntas y Respuestas del Test Runner de Node.js (Cont.)

Short description:

La bandera 'concurrency' permite ejecutar pruebas en paralelo, sacrificando cierto control sobre su orden de ejecución. La velocidad del test runner fue un enfoque principal durante el desarrollo, y es significativamente más rápido que las alternativas. Sin embargo, la cobertura de código no funciona bien con el mecanismo de carga para el soporte de TypeScript, pero esto se está abordando. Se busca activamente retroalimentación para el test runner de los mantenedores y usuarios finales a través de varios canales, incluyendo Twitter y GitHub.

Existe una bandera de concurrencia. ¿Y cómo la controlas? La usas si realmente quieres ejecutar pruebas en paralelo, y pierdes cierto tipo de control porque no las ejecutará una por una. Esta es una elección que debes hacer en función de tu caso de uso. La clásica respuesta de 'depende'. Siempre hay una respuesta de 'depende'.

Y luego otra sobre la velocidad del test runner. ¿Fue una preocupación al construirlo? Porque esto es una gran parte, especialmente cuando estás testing mucho, se convierte en una gran parte de tu tiempo simplemente esperando a que las pruebas se completen. Definitivamente, fue uno de los principales enfoques, y es rápido. No añadí un benchmark en mi presentación, pero puedes encontrarlos en el proyecto Node.js. Es muy rápido en comparación con las alternativas. Eso tiene mucho sentido.

Y otra pregunta también, sobre la cobertura de código, funciona bien cuando usas el cargador... ¿Funciona bien cuando usas el mecanismo de carga para soportar TypeScript? No. Ese es uno de los errores que estamos tratando de corregir ahora mismo. No funciona bien, pero lo haremos funcionar pronto. Y obviamente, solo quiero prevenir esto diciendo que esto es como los primeros días. ¿Y cómo estás recopilando comentarios sobre las características que quizás los desarrolladores quieren o características en las que quizás quieras pasar más tiempo? Exactamente. Node.js se convirtió en LTS el mes pasado. Así que solo ha estado en el mercado durante un mes para el público. Lo hemos estado utilizando internamente. Recopilamos comentarios principalmente de los mantenedores que crean nuevos paquetes y lo usan en su nueva aplicación. Pero realmente nos encantaría que los usuarios finales proporcionaran comentarios en Twitter, en GitHub, en lo que sea. Hay una sección de discusión en Node.js en GitHub donde puedes agregar ideas, mejoras que quieres para el test runner. Sí. Me encanta. Y me encanta cuando hay una especie de bucle de retroalimentación abierto entre las personas que trabajan en proyectos y las personas que los usan. Así que por favor contribuye. Una cosa que me encantó de una de tus diapositivas es que tenías la diapositiva y tenías a Bunn y Dino asomándose. Me recuerda a esta pregunta donde es solo pensamientos sobre el test runner de Bunn. Sí, es muy rápido.

Bunn: Colaboración y Estandarización

Short description:

Bunn es genial para la comunidad, proporcionando inspiración y retroalimentación. Promueve la colaboración y la estandarización a través del grupo de trabajo WinterCG.

Me encanta Bunn. Es genial y está ayudando a toda la community porque nos permite ver lo que la community quiere y cómo lo están haciendo otras alternativas a Node.js. Así que proporciona mucha inspiration y retroalimentación a través de otros runtimes. Sí. Sí. Me encanta cómo es un ecosystem y no solo una competencia entre todos ellos. Todos se ayudan y se construyen mutuamente. Sí. Esto es muy importante. Y ahora hemos creado un grupo de trabajo llamado WinterCG donde todos trabajamos juntos para estandarizar el ecosystem y no ser competidores sino aliados en el ecosystem. Me encanta eso. Y gracias por todo ese duro trabajo que estás haciendo. Tenemos otra pregunta, ¿cuál es el principal problema que estás tratando de resolver? Así que para ellos, parece ser genial para asegurar que los nuevos programadores se introduzcan en el testing, pero tal vez hay más. Cuando empezaste a decidir que querías construir esto en Node.js de forma nativa, ¿cuáles fueron algunas de las grandes motivaciones? Así que una de las grandes motivaciones es que cada otro runtime, cada otro lenguaje de programación tiene su propia biblioteca de pruebas incorporada. No hay lenguaje de programación sin ella y es una de las características clave. Si puedes escribir código, entonces necesitas escribir pruebas también. Hay mucha confusión en el ecosystem debido a la gran cantidad de bibliotecas. Algunas de ellas son buenas, algunas de ellas son malas, y es difícil para un usuario final entender cuáles son buenas y compatibles con Node.js. Así que dijimos, vamos a dar a nuestros usuarios algo bueno, rápido y muy simple de usar. Y la idea es también que el ecosystem construya bibliotecas encima del test runner. Así que en lugar de crear de nuevo un nuevo test runner desde cero, puedes empezar desde algo que funciona y está estabilizado y estandarizado. Sí, creo que es realmente bueno poder tener esas características básicas y tal vez necesites aumentarlas para las cosas específicas que necesitas también, pero eso también es genial para ver a Node.js asumiendo eso. La siguiente pregunta, ya la tocaste en una de las preguntas anteriores, que es sobre performance, y sé que dijiste que puedes mirar en la página web, pero esta persona acaba de preguntar sobre su performance en comparación con Jest o VTest. Es más rápido, especialmente... Me encanta el mic drop, simplemente, es más rápido, boom. Sí, es más rápido, especialmente en comparación con Jest y VTest, porque esos son geniales porque proporcionan todo de una vez, pero son muy lentos, especialmente Jest porque se ejecuta dentro de un módulo VM de Node.js. Así que, sí, definitivamente el test runner nativo es mucho, mucho más rápido, sí. Genial, y solo tenemos tiempo para una pregunta más, que es, ¿qué pasa con las rutas de importación? Así que recuerdo, si recuerdo correctamente, y creo que esto es lo que esta pregunta está tocando en, que es cuando lo trajiste, lo trajiste de la misma manera que usaste con, ¿fue tap? No, no tap, he olvidado cómo se llamaba el otro. Oh, ¿te refieres al prefijo node? Sí, esto es para la estandarización, porque, por ejemplo, BUN tiene algunas de las APIs que son de Node.js para la compatibilidad, y así decidimos añadir un prefijo antes de cada una de nuestras APIs nativas para que otros runtimes también sepan que esto es de Node.js y también los usuarios, si en otros runtimes quieren usar una característica solo de Node.js, pueden simplemente añadir el prefijo y funciona. Así que si estás usando BUN, puedes usar, por ejemplo, el sistema de archivos de Node.js, y es compatible con Node.js. Así que, sí, es algo nuevo, y no hemos hablado mucho de ello, pero deberías usar eso. Genial. Si tienes alguna pregunta más, o tal vez la hice mal y te gustaría aclarar, no dudes en ponerte al día con Marco en la discusión de los ponentes y durante el resto del día. Pero por última vez, vamos a darle un gran aplauso.

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

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.
Node Congress 2022Node Congress 2022
34 min
Out of the Box Node.js Diagnostics
In the early years of Node.js, diagnostics and debugging were considerable pain points. Modern versions of Node have improved considerably in these areas. Features like async stack traces, heap snapshots, and CPU profiling no longer require third party modules or modifications to application source code. This talk explores the various diagnostic features that have recently been built into Node.
You can check the slides for Colin's talk here. 
JSNation 2023JSNation 2023
22 min
ESM Loaders: Enhancing Module Loading in Node.js
Native ESM support for Node.js was a chance for the Node.js project to release official support for enhancing the module loading experience, to enable use cases such as on the fly transpilation, module stubbing, support for loading modules from HTTP, and monitoring.
While CommonJS has support for all this, it was never officially supported and was done by hacking into the Node.js runtime code. ESM has fixed all this. We will look at the architecture of ESM loading in Node.js, and discuss the loader API that supports enhancing it. We will also look into advanced features such as loader chaining and off thread execution.
JSNation Live 2021JSNation Live 2021
19 min
Multithreaded Logging with Pino
Almost every developer thinks that adding one more log line would not decrease the performance of their server... until logging becomes the biggest bottleneck for their systems! We created one of the fastest JSON loggers for Node.js: pino. One of our key decisions was to remove all "transport" to another process (or infrastructure): it reduced both CPU and memory consumption, removing any bottleneck from logging. However, this created friction and lowered the developer experience of using Pino and in-process transports is the most asked feature our user.In the upcoming version 7, we will solve this problem and increase throughput at the same time: we are introducing pino.transport() to start a worker thread that you can use to transfer your logs safely to other destinations, without sacrificing neither performance nor the developer experience.

Workshops on related topic

Node Congress 2023Node Congress 2023
109 min
Node.js Masterclass
Workshop
Have you ever struggled with designing and structuring your Node.js applications? Building applications that are well organised, testable and extendable is not always easy. It can often turn out to be a lot more complicated than you expect it to be. In this live event Matteo will show you how he builds Node.js applications from scratch. You’ll learn how he approaches application design, and the philosophies that he applies to create modular, maintainable and effective applications.

Level: intermediate
Node Congress 2023Node Congress 2023
63 min
0 to Auth in an Hour Using NodeJS SDK
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.JS backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
Table of contents- A quick intro to core authentication concepts- Coding- Why passwordless matters
Prerequisites- IDE for your choice- Node 18 or higher
JSNation Live 2021JSNation Live 2021
156 min
Building a Hyper Fast Web Server with Deno
WorkshopFree
Deno 1.9 introduced a new web server API that takes advantage of Hyper, a fast and correct HTTP implementation for Rust. Using this API instead of the std/http implementation increases performance and provides support for HTTP2. In this workshop, learn how to create a web server utilizing Hyper under the hood and boost the performance for your web apps.
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
WorkshopFree
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
React Summit 2022React Summit 2022
164 min
GraphQL - From Zero to Hero in 3 hours
Workshop
How to build a fullstack GraphQL application (Postgres + NestJs + React) in the shortest time possible.
All beginnings are hard. Even harder than choosing the technology is often developing a suitable architecture. Especially when it comes to GraphQL.
In this workshop, you will get a variety of best practices that you would normally have to work through over a number of projects - all in just three hours.
If you've always wanted to participate in a hackathon to get something up and running in the shortest amount of time - then take an active part in this workshop, and participate in the thought processes of the trainer.