Recientemente migré algunas pruebas de Jest al ejecutor de pruebas de Node.js en dos de mis proyectos que usan MongoDB. En uno de esos proyectos, el tiempo de ejecución de las pruebas fue reducido de 107 segundos a 25 segundos (captura de pantalla abajo). En el otro proyecto, el tiempo de ejecución de las pruebas fue reducido cerca de un 66%.

Decidí compartirte cómo pude implementarlo. Pienso que te será de utilidad, ya que es más rentable (en términos de reducir dinero gastado en ejecutar pruebas en CI/CD), y también mejora tu experiencia de desarrollo.

Tabla de Contenidos

• Pre-requisitos
• El Ejecutor de Pruebas de Node.js
• El Servidor en memoria de MongoDB

• Cómo escribir las Pruebas
  1. Configurar el Proyecto
  2. Configurar el Esquema de Mongoose
  3. Configurar los Servicios
  4. Configurar las Pruebas
  5. Escribir las Pruebas
  6. Pasar las Pruebas
  7. Usar TypeScript (Opcional)

• Conclusión

Pre-requisitos

Para seguir esta guía, deberías de tener experiencia trabajando con Node.js, MongoDB y Mongoose (o cualquier otro mapeador de datos de objetos de MongoDB). Deberías también tener instalado Node.js (al menos la versión 20.18.2) y MongoDB (Compass la versión GUI) en tu computadora.

El Ejecutor de Pruebas de Node.js

El ejecutor de pruebas de Node.js fue introducido como una característica experimental en la versión 18 de Node.js. Se volvió disponible oficialmente en la versión 20. Te da la habilidad de:

1. Ejecutar pruebas
2. Reportar resultados de las pruebas
3. Reportar cobertura de las pruebas (todavía experimental en la versión 23)

Es una buena idea el usar el ejecutor de pruebas incorporado cuando se escriban pruebas en Node.js porque significa que tienes que usar menos dependencias externas. No necesitas instalar una librería externa (y sus dependencias entre pares) para ejecutar las pruebas.

El mejor ejecutor incorporado también es el más rápido. Basado en mi experiencia usándolo en dos proyectos (los cuales usaron Jest), vi mejoras de al menos una reducción del 66% en el tiempo que tomó ejecutar las pruebas completamente.

Y a diferencia de otros frameworks o librerías de pruebas, el ejecutor de pruebas de Node.js fue construido especialmente para proyectos de Node.js. No trata de acomodar las especificaciones de otros entornos de programación como el navegador. Las especificaciones de Node.js son su principal y única prioridad.

El Servidor en memoria de MongoDB

Para las pruebas que involucran el hacer peticiones a una base de datos, algunos desarrolladores prefieren imitar las peticiones para evitar hacer peticiones a una base de datos real. Hacen esto porque hacer una petición a una base de datos real requiere un montón de configuraciones que puede costar tiempo y recursos.

Escribir y solicitar datos usando una base de datos real es más lento comparado con escribir y solicitar datos de la memoria. Cuando se ejecutan pruebas automatizadas, usando un servidor de MongoDB real será más lento que usar un servidor de base de datos en memoria, y ahí es donde mongodb-memory-server se vuelve útil.

Según su documentación, mongodb-memory-server crea y comienza un servidor de MongoDB real de forma programática desde dentro de Node.js, pero usa una base de datos en memoria por defecto. También te permite conectar el servidor de base de datos que crea usando tu mapeador de datos de objetos preferido tales como Mongoose, Prisma, o TypeORM. En esta guía, usaremos Mongoose (v.8.9.6).

Ya que los datos almacenados por mongodb-memory-server reside en la memoria por defecto, es más rápido leer y escribir en él que cuando se usa una base de datos real. mongodb-memory-server también es más fácil de configurar. Estos beneficios lo hace una buena elección para usarlo como un servidor de base de datos para escribir pruebas.

Nota: asegúrate de instalar la versión 9.1.6 de mongodb-memory-server para seguir esta guía. La versión 10 actualmente tiene problemas con limpiar los recursos después que se hacen las pruebas. Mira este problema con el título "Node forking will include any --import from the original command".

El problema ha sido resuelto al tiempo de escribir este artículo, pero el arreglo no ha sido fusionado para las instalaciones.

Cómo escribir las Pruebas

Ahora te guiaré a través de los siguientes pasos para que comiences a escribir las pruebas:

1. Configurar el proyecto
2. Configurar el esquema de Mongoose
3. Configurar los servicios
4. Configurar las pruebas
5. Escribir las pruebas
6. Pasar las pruebas
7. Usa TypeScript (Opcional)

1. Configurar el Proyecto

Creé un repositorio de Github para facilitarte que sigas esta guía. Clona este repositorio en nodejs-test-runner-mongoose y dirígete a la rama 01-setup.

En 01-setup, las dependencias para el proyecto están el archivo package.json. Instala las dependencias usando el comando npm install para configurar el proyecto. Asegúrate de que la configuración esté completa y correcta, ejecuta el comando node . en la terminal de tu proyecto. Deberías ver tu versión de Node.js  como una salida en la terminal.

# instala las dependencias
npm install
...
# ejecuta el comando node
node .
# la salida
You are running Node.js v22.13.1

2. Configurar el Esquema de Mongoose

Configuraremos el esquema para dos colecciones (Task y User) en la rama 02-setup-schema usando Mongoose. Los archivos task/model.mjs y user/model.mjs contienen el esquema para las colecciones Task y User, respectivamente. También configuraremos una conexión de base de datos en index.mjs para asegurar que la configuración del esquema funcione correctamente.

No iré en detalle sobre los modelos y esquemas de Mongoose en este artículo porque están fuera de su alcance.

Cuando ejecutas el comando node . después de implementar los cambios en 02-setup-schema, deberías de ver un resultado similar en la consola como en el fragmento de abajo:

node .
You are running Node.js v22.13.1
Created user with id 679f1d7f73fbeaf23b2007df
Created task "Task title" for user with id "679f1d7f73fbeaf23b2007df"

Puedes ver las diferencias entre 01-setup y 02-setup-schema a través de la diferencia 01-setup <> 02-setup-schema en Github.

3. Configurar los Servicios

Luego, creamos los archivos de servicio (task/service.mjs y user/service.mjs) en la rama 03-setup-services. Ambos archivos actualmente contienen funciones vacías en el que escribiremos las pruebas más tarde. Estas funciones contendrán la lógica de negocio y también se comunicará con la base de datos. Estamos usando comentarios de JSDoc para escribir parámetros y regresar valores.

Haz clic en la diferencia de 02-setup-schema <> 03-setup-services para ver los cambios de código entre 02-setup-schema y 03-setup-services.

4. Configurar las Pruebas

En la rama 04-set-up-tests, configuramos la base de código para ejecutar las pruebas. Creamos test.setup.mjs el cual contiene el código que será ejecutado antes de que cada archivo de prueba se ejecute.

En test.setup.mjs, la función connect crea un servidor de MongoDB en memoria y lo conecta con Mongoose para ejecutar las pruebas. La función closeDatabase cierra la conexión de la base de datos y limpia todos los recursos para liberar memoria.

Las funciones connect y closeDatabase se ejecutan en el hook t.before y en el hook t.after respectivamente. Esto asegura eso, antes que un archivo test se ejecute, una conexión de base de datos se establece a través t.before. Luego de que se hayan ejecutado las pruebas del archivo, la conexión de la base de datos se cae y los recursos usados se limpian a través de t.after.

En package.json, actualizaremos el script de npm test a node --test --import ./test.setup.mjs. Este comando asegura que Módulo Es test.setup.mjs se pre-cargue y se ejecute a través del comando --import del CLI antes de que cada archivo de prueba se ejecute.

Luego crearemos los archivos de prueba con pruebas vacías en las carpetas __tests__ para user y task. Después de implementar los nuevos cambios en 04-set-up-tests, ejecutar el script test con npm run test debería de mostrar la salida similar al fragmento de abajo:

npm run test

> nodejs-test-runner-mongoose@1.0.0 test
> node --test --import ./test.setup.mjs

...

ℹ tests 8
ℹ suites 5
ℹ pass 8
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 941.768873

Todas las pruebas actualmente pasan porque no hay aserciones que fallen. Escribiremos las pruebas con aserciones en la siguiente sección.

5. Escribir Pruebas

Ahora es tiempo de escribir las pruebas para las funciones en los archivos de service en la rama 05-write-tests. Estamos usando la librería de aserción de Node.js para asegurar que los valores regresados de las funciones sean lo que esperamos. Puedes ver las pruebas que hemos escrito cuando comparas las diferencias entre 04-set-up-tests y 05-write-tests.

Cuando el script tests se ejecute, todas las pruebas fallan porque no hemos escritos las funciones en los archivos de service todavía. Debería de ver una salida similar al fragmento de abajo cuando ejecutes el script test:

npm run test

> nodejs-test-runner-mongoose@1.0.0 test
> node --test --import ./test.setup.mjs

...

ℹ tests 8
ℹ suites 5
ℹ pass 0
ℹ fail 8
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0
ℹ duration_ms 1202.031961

6. Pasar las Pruebas

En 06-pass-tests, escribimos las funciones en los archivos de service que pasen las pruebas. Solamente 6 de 7 pruebas pasan cuando el script test se ejecuta porque salteamos la prueba para la función getById en user/service.mjs con t.skip. No hemos terminado la función getById en user/service.mjs. Supuse que podríamos dejarlo como ejercicio.

Cuando ejecutas el script test, deberías obtener una salida similar en la terminal como el de abajo:

ℹ tests 7
ℹ suites 4
ℹ pass 6
ℹ fail 0
ℹ cancelled 0
ℹ skipped 1
ℹ todo 0
ℹ duration_ms 1287.564918

Puedes ver el código que escribimos para pasar las pruebas en los cambios de código entre 05-write-tests y 06-pass-tests.

7. Usa TypeScript (Opcional)

Si tu intención es ejecutar las pruebas con TypeScript, puedes cambiar a la rama 07-with-typescript. Necesitas tener Node.js >=22.6.0 instalado porque estamos usando la opción --experimental-strip-types en el test. Para configurar las pruebas que se ejecuten con TypeScript, sigue los siguientes pasos:

1. Instala TypeScript usando el comando npm install typescript --save-dev
2. Instala tsx usando el comando npm install tsx
3. Crea un archivo predeterminado tsconfig.json en la raíz del proyecto usando el comando npx tsc --init

En  package.json, actualiza el script test a esto:

"test": "node --test --experimental-strip-types --import tsx --import ./test.setup.mjs"

• --experimental-strip-types ayuda a eliminar tipos antes de cada archivo de prueba se ejecute.

Pre-cargar tsx con el --import ayuda a ejecutar el archivo de TypeScript. Sin él, el ejecutor de pruebas no será capaz de encontrar archivos importados sin la extensión .ts. Por ejemplo, user/model.ts importado con el fragmento de código de abajo no será encontrado.

  import { UserModel } from "./model";

El resto de los cambios desde 06-pass-tests a 07-with-typescript involucran actualizar los tipos, cambiar las extensiones de archivo de .mjs a .ts y actualizar las declaraciones import.

Conclusión

En esta guía, has aprendido cómo usar el ejecutor de pruebas incorporado de Node.js y por qué es frecuentemente una mejor elección sobre otras librerías y frameworks de pruebas. También has aprendido cómo usar mongodb-memory-server como un reemplazo de un servidor real de MongoDB, así también como por qué es una buena idea usarlo en vez de un servidor real de MongoDB para las pruebas.

Lo más importante, has aprendido cómo configurar y ejecutar las pruebas en Node.js usando el ejecutor de pruebas de Node.js y mongodb-memory-server. Ahora deberías de saber cómo configurar tus proyectos para que ejecuten las pruebas si usas TypeScript.

Si encuentras útil a este repositorio nodejs-test-runner-mongoose, por favor dale una estrella. Me anima mucho. Gracias.

Todos sabemos que debemos escribir pruebas unitarias. Pero, es difícil saber donde comenzar y cuanto tiempo debemos dedicar a probar comparado a la implementación actual. Entonces ¿dónde comenzar? ¿Y se trata solo de probar el código o las pruebas unitarias tienen otros beneficios?

En este artículo, vamos a explicar los diferentes tipos de pruebas, y que beneficios las pruebas unitarias traen a los equipos de desarrolladores. Mostraré Jest, un marco de pruebas de JavaScript.

Diferentes tipos de pruebas.

Antes de sumergirnos en los detalles de las pruebas unitarias. Quiero  hacer un recorrido rápido a los diferentes tipos de pruebas. A menudo hay cierta confusión  a su alrededor y no estoy sorprendido. A menudo la línea entre ellos es bastante delgada.

Pruebas Unitarias

Las pruebas unitarias solo prueban una sola parte de tu implementación. Una unidad. Sin dependencias, ni integraciones, ni detalles del framework. Son como un método que regresa un link en un lenguaje específico:

export function getAboutUsLink(language){
  switch (language.toLowerCase()){
    case englishCode.toLowerCase():
      return '/about-us';
    case spanishCode.toLowerCase():
      return '/acerca-de';
  }
  return '';
}

Pruebas de integración

En cierto punto, tu código se comunica con una base de datos, el sistema de archivos u otro tercero. Incluso podría ser otro módulo en tu aplicación.

Esa pieza de implementación debe ser probada por las pruebas de integrador. Por lo general, tienen una configuración más complicada que implica preparar entornos de prueba, inicializando dependencias, etc.

Pruebas Funcionales

Las pruebas unitarias y las pruebas de integración te dan la confianza que tu aplicación trabaja. Las pruebas Funcionales ven a la app  desde el punto de vista del usuario y prueba que el sistema trabaja como es esperado.

En el diagrama de arriba, viste que las pruebas unitarias forman la gran base del conjunto de pruebas de aplicación. Por lo general, son pequeños, hay muchos de ellos, y sé ejecutados automáticamente.

Entonces ahora vamos a ver las pruebas unitarias en mayor detalle.

¿Por qué te debes molestarte en escribir pruebas unitarias?

Siempre que pregunto a desarrolladores si escriben prueban unitarias para su aplicación, ellos siempre me dicen:  "No tengo tiempo para ellas" o "No las necesito, yo sé cómo trabaja"

Entonces sonrío educadamente y les digo lo que quiero decirles. La pruebas unitarias no se tratan solo de pruebas. También te ayudan de otras maneras, para que puedas:

Confía en que tu código funciona. ¿Cuándo fue la última vez que cometiste un cambio en el código,  fallo la compilación, y la mitad de tu aplicación dejo de trabajar? La mía fue la semana pasada.

Pero eso todavía está bien. El verdadero problema es cuando la compilación se realiza correctamente, el cambio es llevado, y tu aplicación empieza a ser inestable.

Cuando eso pasa, empiezas a perder confianza en tu código y eventualmente solo pedirás que tu aplicación funcione. Las pruebas unitarias te ayudarán a descubrir errores mucho antes y a ganar confianza.

Tomar mejores decisiones de arquitectónicas. El código cambia, pero algunas decisiones sobre la plataforma, módulos, estructura, y otros cambios se necesitan hacer en tempranas etapas del proyecto.

Cuando empiezas a pensar acerca de las pruebas unitarias justo al inicio, le ayudara a estructurar mejor su código y lograr una separación adecuada de las preocupaciones. No tendrá la tentación de asignar múltiples responsabilidades a un solo bloques de código único, ya que serian una pesadilla para la prueba unitaria.

Identifique la funcionalidad antes de codificar. Escribe la firma del método y comienza a implementarlo de inmediato. Ah, pero ¿qué debería suceder en caso de que un parámetro sea nulo? ¿Qué sucede si su valor está fuera del rango esperado o contiene demasiados caracteres? ¿Lanza una excepción o devuelve null?

Las pruebas unitarias ayudarán a descubrir todos los casos. Mira las preguntas otra vez y encontrarás exactamente que definirás tus casos de pruebas unitarias.

Estoy seguro de que hay muchos otros beneficios de escribir pruebas unitaria. Estos solo algunos de los que recuerdo por mi experiencia. Estos los he aprendido de la manera difícil.

Como escribir tu primera prueba unitaria de JavaScript

Pero vamos a regresar a JavaScript. Vamos a empezar con Jest, que es un marco de pruebas de JavaScript. Es una herramienta que permite realizar  pruebas unitarias automáticas, proporciona  cobertura de código, y nos permite simular fácilmente objetos. Jest también tiene una extensión para Visual Studio Code disponible aquí.

También hay otros marcos, si tú estás interesado, tú puedes revisarlos en este artículo.

npm i jest --save-dev

Vamos a usar el método mencionado anteriormente getAboutUsLink como una implementación que queremos probar:

const englishCode = "en-US";
const spanishCode = "es-ES";
function getAboutUsLink(language){
    switch (language.toLowerCase()){
      case englishCode.toLowerCase():
        return '/about-us';
      case spanishCode.toLowerCase():
        return '/acerca-de';
    }
    return '';
}
module.exports = getAboutUsLink;

Puse esto en el archivo index.js . Podemos escribir pruebas en el mismo archivo, pero una buena práctica es separar las pruebas unitarias en archivo dedicado.

Los patrones de nomenclatura  incluyen {filename}.test.js y {filename}.spec.js. Utilice el primero, index.test.js:

const getAboutUsLink = require("./index");
test("Returns about-us for english language", () => {
    expect(getAboutUsLink("en-US")).toBe("/about-us");
});

Primero, necesitamos importar la función que queremos probar. Cada prueba se definía como una invocación de  función test.  El primer parámetro es el nombre de la prueba para su referencia. El otro es una función de flecha donde llamamos a la función que queremos probar y especificamos que resultado esperamos.

En este caso, llamamos a la función getAboutUsLink con en-US como parámetro de lenguaje. Esperamos que el resultado sea /about-us.

Ahora podemos instalar el Jest CLI globalmente y ejecutar la prueba:

npm i jest-cli -g
jest

Si ve el error relacionado con la configuración, asegúrese de tener presente  el archivo package.json.  En ese caso que no lo hagas, genera uno usando npm init.

Debes ver algo como esto:

 PASS  ./index.test.js
  √ Returns about-us for english language (4ms)
  console.log index.js:15
    /about-us
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.389s

¡Buen trabajo! Este fue la primera prueba unitaria simple JavaScript desde el principio al fin. Si tienes instalado la extensión Visual Studio Code, ejecutará la prueba automáticamente una vez salvado el archivo. Vamos a intentarlo extendiendo la prueba con esta línea:

expect(getAboutUsLink("cs-CZ")).toBe("/o-nas");

Una vez salvado el archivo,  Jest te informará que la prueba ha fallado. Esto te ayuda a descubrir potenciales problemas, inclusive antes de cometer un cambio.

Probando funcionalidad avansada y servicios de simulación

En la vida real, los códigos  de idioma para el método getAboutUsLink no serían constantes en el mismo archivo. Su valor se usa típicamente en todo el proyecto, por lo que se definirían en su propio módulo y se importarían a todas las funciones que las usan.

import { englishCode, spanishCode } from './LanguageCodes'

Puedes importar estas constantes dentro de la prueba de la misma manera. Pero la situación se complicaría si trabajas con objetos en lugar de simples constantes. Echa un vistazo a este método:

import { UserStore } from './UserStore'
function getUserDisplayName(){
  const user = UserStore.getUser(userId);
  return `${user.LastName}, ${user.FirstName}`;
}

Este método utiliza  UserStore importado:

class User {
    getUser(userId){
        // logic to get data from a database
    }
    setUser(user){
        // logic to store data in a database
    }
}
let UserStore = new User();
export { UserStore }

En orden, para hacer una prueba unitaria de este método, necesitamos simular UserStore. Una simulación es un substituto del objeto original. Nos permite separar dependencias y datos reales de los métodos probados implementados justo como los dummies ayudaban a las pruebas de choquen de autos en lugar de personas reales.

Si no usamos el simulacro, estaríamos probando tanto esta función como la tienda. Eso sería una prueba de integración y probablemente tendríamos que simular una base de datos utilizados.

Simulación de servicios

Para simular objetos, puede proporcionar una función de simulación o una simulación manual. Me centraré en esto último, ya que tengo un caso de uso simple y llanamente. Pero siéntase libre de echar un vistazo a otras posibilidades de simulación que Jest ofrece.

jest.mock('./UserStore', () => ({
    UserStore: ({
        getUser: jest.fn().mockImplementation(arg => ({
            FirstName: 'Ondrej',
            LastName: 'Polesny'
        })),
        setUser: jest.fn()
    })
}));

Primero, necesitamos especificaciones que hemos simulado- el módulo ./UserStore.  Siguiente, necesitamos regresar la simulación que contiene todos los objetos exportados del módulo.

En esta muestra, es únicamente el objeto User nombrado UserStore  con la función getUser. Pero con las implementaciones reales, la simulación podría ser mucho más larga.  Cualquier función que no  importe  el resultado de la prueba unitaria puede ser fácilmente simulada con jest.fn().

La prueba unitaria para la función getUserDisplayName es simular a la que hemos creado antes:

test("Returns display name", () => {
    expect(getUserDisplayName(1)).toBe("Polesny, Ondrej");
})

Tan pronto como he salvado el archivo, Jest me dice que ha pasado dos pruebas. Si tú estás ejecutando las pruebas manualmente,  hazlo ahora y asegúrate que tienen el mismo resultado.

Informe de cobertura de código

Ahora que sabemos como probar el código JavaScript, es bueno cubrir la mayor cantidad de código como sea posible con pruebas. Y eso es difícil de  hacer. Al final, solo somos personas. Queremos que nuestras tareas y las pruebas unitarias generalmente producen una carga de trabajo no deseada que tendemos a pasar por alto. La cobertura de código es una herramienta que nos ayuda a combatir eso.

La cobertura de código te dirá que tan grande es la proporción de tu código, es cubierta por las pruebas unitarias. Tomemos, por ejemplo, mi primera prueba de unitaria comprobando la función getAboutUsLink:

test("Returns about-us for english language", () => {
   expect(getAboutUsLink("en-US")).toBe("/about-us");
});

Revisa el link en inglés, pero la versión en Español no se ha probado. La cobertura de código es 50%. La otra prueba unitaria es verificar la función getDisplayName a fondo y su cobertura de código es el 100%. En conjunto, la cobertura total de código es del 67%. Tenemos  3 casos de uso para probar, pero nuestras pruebas solo cubren dos de ellas.

Para ver el reporte de cobertura de código, escribe el siguiente comando en la terminal:

jest --coverage

O, si tú estás usando Visual Studio Code con la extensión Jest, tú puedes ejecutar el comando (CTRL+SHIFT+P) Jest: Toggle Coverage Overlay. Le mostrará justo en la  implementación que líneas de código no están cubiertas por la prueba.

Ejecutando la revisión de cobertura, Jest también creará un reporte HTML. Encuéntralo en la carpeta del proyecto en coverage/lcov-report/index.html.

Ahora, no tengo que mencionar que debe esforzarse por obtener una cobertura de código del 100%, ¿verdad? :-)

En resumen

En este artículo, muestra como empezar con las pruebas unitarias en JavaScript. Si bien es bueno que su cobertura de código brille al 100% en el informe, en realidad, no siempre es posible(significativamente) llegar ahí. El objetivo es permitir que las pruebas unitarias te ayuden a mantener tu código y de asegurarte de que siempre funcione como es previsto. Te permiten:

• claramente, define la implementación de los requerimientos.
• diseñar mejor su código y separación de preocupaciones
• descubrir los problemas que puede introducir con tus nuevos commits.
• y darte la confianza de que tu código trabaja.

El mejor lugar para empezar es la página  Getting started en la documentación Jest así tú puedes probar estas prácticas por ti mismo.

¿Tienes tu propia experiencia con pruebas de código? Me encantaría escucharlo, déjamelo saber en twitter o únete a alguno de mis streams Twitch.