Pruebas sin dependencias con Node.js

¡Hola a todos! Gracias por venir a mi charla. Hoy voy a hablar sobre las pruebas sin dependencias con Node.js, lo que significa que puedes comenzar a escribir tus pruebas unitarias, pruebas de integración, sin tener que instalar nada desde NPM.

Antes de adentrarnos en la naturaleza del nuevo ejecutor de pruebas de Node, quería hablar un poco sobre por qué se deseaba un ejecutor de pruebas en primer lugar. Casi todos los proyectos necesitan un ejecutor de pruebas. Ya sea que estés construyendo una aplicación o un módulo que planeas publicar en NPM o cualquier otra cosa, si planeas que otras personas usen tu código, casi seguramente necesitas pruebas para ello. Y luego, Node.js ha incluido desde hace años una biblioteca de aserciones realmente buena que se importa simplemente como assert. Esta es la biblioteca de aserciones que he estado usando durante años. Me gusta, así que eso es una dependencia menos. Y luego, la mayoría de los ejecutores de pruebas se superponen mucho en términos de funcionalidad de todos modos. Así que, ya sabes, cada ejecutor de pruebas ejecuta algunas pruebas. Por lo general, tienen características como tiempos de espera, informes sobre qué pruebas pasaron y fallaron, saltar pruebas, cosas así. Así que, hay diferencias, algunos ejecutores de pruebas son más adecuados para el desarrollo front-end, algunos hacen cosas como inyectar variables globales en tu código sin que lo sepas, algunos ejecutan sus pruebas dentro de diferentes contextos, por lo que podrías tener resultados sorprendentes cuando verifiques la igualdad y cosas así. Pero, ya sabes, hay estas pequeñas imperfecciones, pero en general, muchos ejecutores de pruebas tienen muchas funcionalidades superpuestas.

Y además, NPM es realmente un lugar peligroso. A lo largo de los años, ha habido varios incidentes, como left pad, la cosa de colors JS, incluso más recientemente, el paquete minimist, que creo que tiene como 50 millones de descargas o algo así, no le pasó nada en NPM, pero el repositorio de GitHub desapareció. Así que, todas estas dependencias de terceros que estás asumiendo conllevan ciertos riesgos y costos. Y eso es solo una razón por la cual tener un ejecutor de pruebas incorporado, creo, es útil. Y también, hay una tendencia general a tener más de estas cosas incluidas en los entornos de ejecución. Así que, ya sabes, ahora Node tiene un ejecutor de pruebas incorporado. Estoy bastante seguro de que Bun tiene uno, sé que Deno tiene uno. Esto se está volviendo cada vez más común. Y luego, aquí está mi tweet de hace más de un año, creo que Node debería incluir un ejecutor de pruebas y, ya sabes, me siento bastante seguro al respecto. Algunas de las características del nuevo ejecutor de pruebas, puedes ejecutarlo a través de la interfaz de línea de comandos (CLI) que ahora tiene Node con la bandera --test. O puedes ejecutar un archivo independiente que contenga pruebas. Así que, digamos que tienes tu archivo foo.js, puedes decir Node foo.js y si estás usando el ejecutor de pruebas allí, seguirá funcionando. En cuanto a escribir las pruebas en sí, admitimos código síncrono, código basado en promesas o async/await. E incluso, ya sabes, porque Node todavía tiene muchas API basadas en devoluciones de llamada, también admitimos pruebas basadas en devoluciones de llamada. Si vienes de un ejecutor de pruebas como tap o tape, entonces admitimos pruebas de estilo tap, utilizando la función test. Si vienes de un ejecutor de pruebas como Mocha o Jest, tenemos las funciones describe e IT. Bajo el capó, todo utiliza test, describe e IT se implementan de manera similar.

parte superior de la prueba. Pero, ya sabes, si estás buscando esa API familiar, está ahí. Admitimos pruebas anidadas, por lo que puedes tener, ya sabes, una prueba con pruebas arbitrariamente anidadas dentro de ella. Lo mismo si tienes describe. Puedes tener suites que contengan más suites y más pruebas y cosas así. Saltar y hacer pruebas. Así que, ya sabes, si solo quieres saltar una prueba, hay varias formas diferentes de hacerlo. Hacer es similar a saltar en el sentido de que no hará que tu conjunto de pruebas falle. Pero aún ejecutará la prueba y no le importará el resultado. También tenemos solo pruebas. Entonces, si inicias el ejecutor de pruebas de la CLI con guión guión solo pruebas, solo se ejecutarán las pruebas que hayas anotado como solo pruebas. Y también puedes filtrar las pruebas por el nombre de la prueba. Entonces, si usas el patrón de nombre de prueba guión guion guion, en realidad puedes pasar una expresión regular y node solo ejecutará las pruebas cuyos nombres coincidan con ese patrón. Entonces, si quisieras escribir una prueba, ¿cómo se vería? Aquí tienes un ejemplo muy sencillo que utiliza solo el módulo assert de node y el módulo de pruebas de node. Aquí tenemos dos pruebas. Una es una prueba sincrónica que pasa y la otra es una prueba asíncrona que falla. La prueba asíncrona, aunque parece código sincrónico, es una función asíncrona, por lo que devuelve una promesa. Esa promesa se rechaza cuando la aserción falla. Entonces, dos cosas que vale la pena mencionar aquí es que verás que estamos usando node dos puntos prueba. El prefijo node dos puntos se puede usar para importar cualquier módulo principal de node. Pero a partir del módulo de prueba y probablemente con todos los módulos agregados al núcleo de node en el futuro, debes usar el prefijo node dos puntos. Si intentas usar solo la palabra prueba aquí, en realidad intentará cargar desde el espacio de usuario. Y hablando del espacio de usuario, el ejecutor de pruebas en sí está publicado en NPM. Por ahora, el ejecutor de pruebas existe en node 18 y 16. Node 14 aún es compatible, sin embargo. Entonces, algunas personas tomaron el código del núcleo de node, lo adaptaron para que funcione en un módulo de NPM, y lo publicaron. Entonces, simplemente puedes instalar prueba si estás en node 14 y aún tendrás acceso a todas estas funcionalidades. Después de ejecutar tus pruebas, esto es cómo se verá la salida. Esta salida se llama tap, que significa protocolo de pruebas anything. Y no es la más fácil de analizar para los humanos, pero puedes hacer cosas interesantes como, ya sabes, redirigirla a diferentes informes y cosas así, y tener un formato diferente. Pero puedes ver aquí que tenemos okay 1, esa es la primera prueba, que fue la sincrónica que pasó

prueba. Pasó en 1.87 milisegundos. Y luego la segunda prueba no estuvo bien. No estar bien es cómo tap indica un fallo. Puedes ver que hubo un fallo en el código de la prueba. Esperábamos la aserción... afirmamos que el valor 1 sería igual a 2, y claramente no lo es. Así que la prueba falló.

Y luego en la parte inferior, tenemos un pequeño resumen de las pruebas. Se ejecutaron dos pruebas que una pasó, una falló, cero se cancelaron, cero se omitieron. No hay pruebas pendientes. Y luego todo el proceso tomó aproximadamente 11 milisegundos.

Así que solo algunas de las tareas futuras para el ejecutor de pruebas. Tenemos una solicitud de extracción que está abierta en este momento para un analizador de tap. Esto nos permitirá obtener mejores informes dentro del ejecutor de pruebas de la CLI. La CLI para cada archivo que va a ejecutar, genera un proceso secundario que genera su propio tap. La forma en que funciona ahora es que si hay un fallo, simplemente tomamos toda la salida estándar y el error estándar de ese archivo y lo mostramos. Si no hay pruebas fallidas, entonces simplemente decimos que pasó y no mostramos ninguna salida. El analizador de tap nos permitirá analizar inteligentemente esa salida y mostrar las cosas de manera más agradable. También queremos usar el analizador de tap para desarrollar informes. Como dije antes, tap no es lo más bonito de ver. Queremos implementar algunos informes que puedan transformarlo en algo un poco más fácil de leer para los humanos. Luego nos gustaría agregar cobertura de código y simulación, porque estas son dos características bastante importantes que realmente hacen que un ejecutor de pruebas se sienta maduro, en mi opinión. Así que el ejecutor de pruebas aún se considera experimental, pero no espero que haya muchos, si es que hay alguno, cambios importantes en él. Tengo aquí un enlace a la documentación. Animo a todos a que lo prueben al menos una vez. Eso es todo lo que tenía. Gracias por venir. Adiós.