Testing the Waters With Deno

Hoy, como se introdujo, vamos a hablar sobre las pruebas en Deno. Entonces, primero que nada, ¿cuántos de ustedes escriben pruebas en su código hoy? Bien, eso es lo que nos gusta ver. El resto de ustedes, ¿qué están haciendo? Y supongo que la mayoría de ustedes están usando Jest, VTest, Mocker, Jasmine, ¿tal vez? Bien, interesante. Y mientras configuraban eso, ¿cuántos de ustedes recuerdan el infierno de configurar su compilador de TypeScript correcto, emitiendo los mapas de origen correctos, y todo el otro caos que tienen al configurar su entorno de pruebas y sus ejecutores de pruebas? Lo bueno de Deno es que tenemos este tipo de entorno con baterías incluidas. Nuestro enfoque para las herramientas es que deberían ser parte de toda la experiencia del desarrollador. Así que Deno tiene su compilador de TypeScript, tiene sus pruebas, su linting, todo ya integrado, lo que significa que puede escribir sus pruebas en TypeScript cuando está usando Deno. No necesita hacer una gran cantidad de configuración. Así que sé que ya están acostumbrados a las pruebas, han escrito pruebas antes, generalmente, supongo que en Node. Así que no voy a hacer una gran introducción sobre qué son las pruebas y por qué deberían hacer pruebas, pero sí voy a hablarles sobre la herramienta de pruebas de Deno. Es una forma ligeramente opinada de escribir pruebas. Pero si están usando algo como Jest o Mocker, sus pruebas probablemente también se ejecutarán en Deno con muy pocos cambios.

Así que voy a asumir que tenemos una computadora que ya tiene Deno instalado y voy a configurarnos con un proyecto de Deno muy básico. Así que solo voy a decir Deno init, ¿pueden ver esto, por cierto, es lo suficientemente grande? ¿Un poco más grande? Excelente. Así que lo que Deno init ha hecho es configurarme con un proyecto básico aquí. Así que tengo un main.ts, que tiene una función de suma realmente básica, y tengo un main.test. Así que esto es lo que vamos a usar para escribir nuestras pruebas. Deno.test nos permite definir nuestros casos de prueba reales, y lo que hemos hecho aquí es importar nuestra función de suma de nuestro main.ts, y hemos importado este assert equals, que nos va a permitir hacer algunas afirmaciones. Y podemos hacer tanto funciones anónimas como funciones nombradas si queremos, así que de hecho, vamos a hacer trampa en esto. Voy a simplemente pegar eso aquí. Así que también podemos tener una prueba con una función nombrada. Así que aquí estamos probando números negativos. También podemos hacer una prueba ignorada si quisiéramos, así que claro, adelante, Copilot. Bien. De acuerdo, así que esta prueba va a ser ignorada porque hemos usado ignored true allí. Y si queremos ejecutar una prueba con múltiples pasos, por ejemplo, absolutamente podemos hacer eso también. Así que probemos con pasos. Así que lo que quiero hacer es, de hecho, voy a hacer trampa en este también y simplemente pegarlo y luego lo discutiremos. Así que podemos configurar algo que se va a ejecutar antes de todas nuestras pruebas. Luego tenemos nuestro t, que nos va a permitir avanzar paso a paso para que podamos definir múltiples pasos que podríamos querer hacer en nuestra prueba. Y cada paso puede tener su propio nombre y se va a informar por separado en nuestros resultados de prueba.

Entonces, ¿por qué no intentamos y realmente ejecutamos esto. Así que ejecutemos dno test. Y podemos ver que tenemos algunas pruebas, algunas de nuestras pruebas han pasado. Nuestra prueba ignorada ha sido ignorada y nuestros pasos han sido seguidos. Así que podemos ver aquí que tenemos con pasos ejecutándose antes de todos nuestros pasos, paso uno, paso dos. Podemos ver que hemos hecho algunos buenos pasos a través de nuestras pruebas.

Si vienes de algo como Mocha o Jest, también tenemos las pruebas al estilo BDD. Así que si prefieres usar algo como describe e it, absolutamente puedes hacerlo. Así que podemos en lugar de nuestros equals, podemos usar describe e it y before each. Así que estos vienen de la biblioteca de pruebas BDD. Así que estos son parte de la biblioteca estándar de dno, que es solo un montón de código que encontrarás que necesitas a menudo en tus proyectos. La biblioteca estándar te los ofrece.

Hagámoslo, ahí vamos. Y también podemos añadir expect. De hecho, necesitamos mantener nuestro add allí, ¿no? Y este está en el módulo expect. Ahí vamos. Y luego si queremos cambiar nuestra sintaxis de prueba, absolutamente podemos hacerlo. Así que podemos hacer un describe en su lugar. Así que vamos a describir nuestra función add y diremos dentro de aquí, debería devolver la suma de dos números. Sí, eso se ve bien. Sí. Claro. Y también podemos añadir nuestras pruebas negativas. Aquí vamos. Sí. Gracias, CoPilot. Bien. Así que estos deberían ser un poco más reconocibles para ti si vienes de Jest o Mocha. Y también podemos usar nuestro before each si queremos. Podemos decir before each, claro.

Pon algo de texto ahí fuera. Y esto se ejecutará antes de cada una de nuestras pruebas. Así que si intentamos ejecutar eso de nuevo. ¿Qué ha pasado por alto CoPilot? ¿Qué esperas aquí? ¿Un rizo acogedor? Ahí vamos. Así que una salida muy similar a la que vimos antes. Pero quizás con una sintaxis a la que estás más acostumbrado a usar.

Y vimos brevemente el paquete assert antes. Así que también podemos hacer una gran cantidad de diferentes tipos de assertions. Así que podemos assert equals, assert array includes, assert almost equals. Así que vimos nuestro assert básico antes. Solo estoy destruyendo el escenario. No me hagas caso. Pero también podríamos hacer, por ejemplo, llevémoslo todo de vuelta a nuestro assert.

Ahí vamos. Así que tenemos nuestro add. Podemos tener assert aquí. Podríamos assert array includes. Y podemos... Así que hemos visto ese assert equals. Podríamos hacer algo como assert array includes aquí. Podríamos hacer assert throws. Hay una gran cantidad de diferentes herramientas integradas aquí para ti. Y hay una instancia de... Falta una S. Ahí vamos. Bien. Intentemos ejecutar estos. Bien. También hay cosas como assertions de string, tipo y Boolean. Solo aquí para ayudarte a escribir pruebas más expresivas.

Y hay cosas como assert almost equals para ayudarte a comparar cosas como números de punto flotante. Y tenemos... Sí. Como mencioné, tenemos nuestro assert throws, tenemos nuestro assert instance of...

Esta es una oferta muy completa que debería cubrir la mayoría de las bases para la mayoría de tus necesidades de prueba. Y en este momento, solo me ves ejecutar estos con Deno test. Pero escribir eso constantemente sería molesto. Así que, por supuesto, hay una bandera watch.

Así que podríamos decir... Y eso observará cualquier cambio en nuestras pruebas y seguirá ejecutándose. Podemos ver que nuestra prueba ha fallado porque nuestro array no incluye todos los elementos.

Y también puedes filtrar si quieres tal vez omitir una prueba. Así que podría decir, por ejemplo... Déjame poner eso de nuevo. Deno test menos watch. Y luego podría decir filter. Y quiero filtrar cualquier cosa que tenga assert en ella. Y eso solo va a ejecutar las pruebas que tengan la palabra assert en el nombre.

Deno también soporta cobertura de código de forma nativa. Así que puedes generar un informe de cobertura de código. Así que hagámoslo. Deno test menos menos coverage. Eso me va a mostrar cuánto de mi main TS está cubierto por mis pruebas. Así que test menos menos coverage va a ejecutar las pruebas y luego generar un informe de cobertura.

También podría hacer Deno coverage. Lo cual solo va a mostrar el informe de cobertura en el terminal. También podemos, si queremos, seleccionar un directorio para guardar ese informe de cobertura. Así que podríamos hacer Deno test menos menos coverage. Y luego el nombre de nuestra carpeta a donde queremos enviar la cobertura. Debería haber creado una pequeña carpeta para nosotros. Ahí vamos. Que contiene nuestro informe de cobertura.

Y también tenemos soporte para XML estilo JUnit. Si prefieres que tus informes estén en ese formato. Útil para canalizaciones CICD y otras herramientas que esperan ese formato de informe de cobertura.

Quiero decir, podemos ver aquí que solo hemos cubierto el 50% de nuestro main TS porque básicamente hemos probado solo la función add. No hemos probado esta verificación para import meta. Está bien. Podríamos mejorar nuestra cobertura de pruebas si quisiéramos.

Deno también soporta pruebas de snapshot de forma nativa. Lo cual puede ser útil para afirmar si tus modelos de objetos complicados son de la manera que esperarías que fueran.

Así que vamos a configurar una prueba de snapshot. Voy a eliminar todo esto. Voy a importar. Insertar snapshot. Desde JSR colon sdd. Insertar snapshot. Sí, eso es lo que queremos. Y luego vamos a hacer trampa en este de nuevo porque tenemos muy poco tiempo.

Tenemos nuestro... No. Solo vamos a configurar un objeto realmente básico aquí. Así que diremos, claro, eso se ve bien. Y luego haremos un peso assert snapshot. Y ahora cuando ejecutemos nuestra prueba, queremos establecer ese snapshot.

Haremos Deno test menos R menos W, lo que nos dará permiso de lectura y escritura. Así que Deno podrá leer el archivo de snapshot, escribir en un archivo de snapshot, y diremos menos, menos, menos, actualizar. ¿Qué me he perdido? Probando snapshot. Ahí vamos. Genial, así que eso debería haber creado algunos snapshots para nosotros. Y podemos ver aquí que se ha creado un snapshot. Luego, si estuviéramos ejecutando nuestras pruebas de nuevo.

Así que tal vez algo cambie en nuestro objeto y queramos probar si ese snapshot coincide. Entonces diríamos Deno test menos A, y podemos verificar que nuestro snapshot coincide.

Bien, dos minutos para mostrarte una aplicación completa en memoria. Sé que tus pruebas son mucho más complicadas que esto. Sé que tus aplicaciones son mucho más complicadas que esto. Quieres estar probando aplicaciones más grandes.

Así que lo que vamos a hacer es hacer trampa y simplemente arrastrar una aplicación completa. Así que aquí tenemos un buen básico. Esto solo nos va a configurar un pequeño servidor HTTP. Estamos usando Hono para hacer eso. Vamos a instalar Hono, con suerte. Ahí vamos.

Bien, solo una aplicación súper básica, que nos va a configurar un endpoint en slash weather, que tiene algo de información meteorológica en él. Y aquí, estamos haciendo algunas pruebas. Así que estamos probando que hemos configurado correctamente nuestro servidor HTTP. Estamos probando que en la raíz, obtenemos una respuesta de hello world. Y estamos probando que en la ruta del clima, obtenemos algún tipo de datos meteorológicos. Y luego estamos probando que en cualquier otra cosa, obtenemos un 404.

Así que podemos ejecutar Deno test aquí. Oh, coloquemos eso y coloquemos eso. Intentemos eso de nuevo. Y tengo que ejecutar esto con permisos porque estamos haciendo cosas a través de la red. Así que simplemente le di el menos A allí para obtener sus permisos. Así que lo que estamos haciendo aquí es una especie de prueba de componentes, estamos avanzando y probando que nuestro pequeño servidor HTTP está haciendo exactamente lo que esperamos que haga.

Pero dependemos de este fragmento de datos meteorológicos aquí. Y podríamos querer tal vez simular eso. Y absolutamente podemos hacer eso también. Así que saltemos a este ejemplo aquí. Así que podemos, en su lugar, inyectar esa dependencia meteorológica en su lugar. Así que crearemos un nuevo archivo que es nuestro servicio meteorológico. Así que aquí es donde estarán nuestros datos meteorológicos. Inyectaremos eso en nuestro main TS. Y luego en nuestro main TS, podemos simular un clima diferente tal vez. Así que echemos un vistazo. Ahora podemos crear nuestro servicio meteorológico falso. Y podemos verificar si nuestra aplicación va a funcionar de la manera que esperamos si el clima cambia, por ejemplo.

Genial. Así que esa es una especie de, voy a decir, enfoque rudimentario para las pruebas de dependencias. Es un ejemplo muy básico. Pero espero que esto haya sido una especie de introducción rápida a las pruebas muy simples en Deno. No tuvimos que configurar nada. Tenemos todas nuestras importaciones útiles de la biblioteca estándar de Deno. Así que sí, ve y prueba con Deno. Oh, hay pegatinas al frente. Así que ven a tomar pegatinas. Y también tengo una caja gigante de hermoso swag, porque Deno no es solo un runtime de JavaScript. Ahora, aparentemente, también es una marca de ropa.

Tenemos muchas preguntas para ti. No tenemos mucho tiempo. Oh, lo siento. No hay problema en absoluto. También habrá una estación de preguntas y respuestas abajo después de esto. Y pueden encontrarte allí, ¿verdad? Muy bien. Vamos directo a ello.

¿Qué características de Jest y Vitest no son compatibles con Deno en este momento y podrían necesitar una reescritura? Es decir, ¿que Deno podría necesitar una reescritura de? Que necesitamos reescribir. Así que no lo sé. Elige tu opción. ¿Quién necesita reescritura? Quiero decir, el marco de pruebas de Deno, lo admito completamente, no está tan completo como Jest y Vitest. Así que recomiendo absolutamente usarlos, pero quizás usarlos junto con el marco de pruebas de Deno. Sabes, absolutamente funcionarán en Deno. Así que sí, admito que hay muchas características en Jest y Vitest que no están en el marco de pruebas de Deno. Muy bien. Sabes lo que hiciste aquí, ¿verdad? Al introducir que hay pegatinas y swag, esto va a ser interesante. Muy bien. ¿Cómo se ven las simulaciones de módulos y paquetes? ¿O cómo se ven las simulaciones de módulos y paquetes en las pruebas de Deno? No se ven. No se ven.

No lo hace. No parece. Sí. Lamentablemente, las pruebas de dependencias de módulos no son realmente posibles en Deno test en este momento. Así que sí, el ejemplo que mostré es un ejemplo súper básico. Pero sí, probablemente querrás estar usando Vitest. Vitest es mi favorito si eso es lo que quieres hacer. Muy bien.

Tal vez un comentario para ti. La página de documentación oficial parece un poco confusa. ¿Hay una mejor fuente para encontrar más información? Quiero decir, siento que ir a tu charla sería un buen lugar para comenzar. Ven a buscarme, la persona que dice que parece confusa, porque la documentación es mi orgullo y alegría. Yo escribo la documentación de Deno. Así que si no te parece bien, ven a mostrarme qué no se ve bien y lo arreglaré porque... Sí. Muy bien. Muy bien.

Rápidamente repasándolos. Hagamos una pregunta más. Así que un cierto objeto anidado complejo puede volverse bastante engorroso en Vitest y Jest. ¿Es lo mismo para Deno? Lo es. Sí. Lamentablemente. Sí. Lamentablemente. Sí, realmente no tengo una respuesta... Quería preguntar cuál es la ventaja. Muy bien. Genial. Haremos una más, solo para asegurarnos de que terminamos en una nota alta.

¿Hay una manera fácil de reescribir un conjunto de pruebas de, por ejemplo, Jest a Deno Runner? ¿Hay algún framework que sea más fácil de cambiar a Deno que otros? Oh, ¿sabes qué? No sé cuál sería el más fácil. Debería haber cambios muy mínimos para ejecutar tus pruebas en Deno. Así que TouchWood debería funcionar perfectamente si estás usando Vitest con Deno. Si estás usando Jest con Deno, todo esto debería funcionar bien. Si quieres cambiarlo, obviamente, habrá un poco de edición para usar la funcionalidad de prueba de Deno. Pero sí, quiero decir, tal vez es algo en lo que deberíamos pensar para el futuro como una herramienta de conversión si eso es algo que a la gente le podría gustar. Pero aún no existe. Muy bien.

Bueno, Jo, muchas gracias por tu charla nuevamente. Un placer. Gracias.