Explorando Node.js Test Runner

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.

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.

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.

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.

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.

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.

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.

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...

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.

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.