Pruebas de integración de JavaScript con Docker: de la A a la Z
\n\nEn el desarrollo web moderno, la calidad del código no es solo una métrica, sino la clave para la estabilidad del producto. Las pruebas de integración (Integration Testing) ocupan un lugar clave en la pirámide de pruebas, permitiendo verificar la interacción entre diferentes módulos, bases de datos, API externas y servicios. Sin embargo, configurar entornos aislados y reproducibles para estas pruebas a menudo se convierte en un dolor de cabeza. Aquí es donde Docker viene al rescate: una herramienta de contenerización ideal para crear entornos de prueba limpios y repetibles.
\n\nEn este artículo, analizaremos cómo organizar las pruebas de integración para aplicaciones JavaScript (Node.js) usando Docker. Aprenderá cómo levantar una base de datos de prueba, ejecutar dependencias en contenedores y escribir pruebas efectivas que se puedan integrar fácilmente en un pipeline de CI/CD.
\n\n1. ¿Por qué Docker es ideal para las pruebas de integración?
\n\nEl enfoque tradicional de las pruebas de integración a menudo requiere la configuración manual del entorno en cada máquina de desarrollo o servidor CI. Esto lleva al problema de "en mi máquina funciona". Docker resuelve este problema de forma radical:
\n\n- \n
- Aislamiento: Cada prueba se ejecuta en un contenedor limpio, eliminando la influencia de efectos secundarios de ejecuciones anteriores. \n
- Reproducibilidad: El mismo entorno (versión de Node.js, bases de datos, bibliotecas del sistema) funciona garantizadamente en todas partes: en la máquina local del desarrollador, en el servidor de compilación y en producción. \n
- Gestión de dependencias: Puede levantar fácilmente infraestructuras complejas (Redis, PostgreSQL, RabbitMQ) con un solo comando
docker-compose up -d. \n - Velocidad: Los contenedores se inician en segundos, a diferencia de las máquinas virtuales. Docker almacena en caché las capas, lo que acelera las compilaciones repetidas. \n
En el contexto de Node.js, Docker permite "simular" servicios externos sin salir del entorno de desarrollo. En lugar de conectarse a una API de producción, levanta un contenedor de prueba con, por ejemplo, json-server o testcontainers.
2. Configuración del proyecto Node.js para pruebas
\n\nSupongamos que tenemos una aplicación Express simple que guarda usuarios en PostgreSQL. Nuestra tarea es probar el endpoint POST /users.
Estructura del proyecto:
\n\nproject/\n├── src/\n│ ├── app.js\n│ ├── db.js\n│ └── routes/\n│ └── users.js\n├── test/\n│ └── integration/\n│ └── users.test.js\n├── docker-compose.test.yml\n├── Dockerfile\n├── package.json\n└── .env.test\n\n\n
Para las pruebas usaremos el stack popular: Mocha (framework) + Chai (biblioteca de aserciones) + Supertest (pruebas HTTP).
\n\nInstalemos las dependencias:
\nnpm install --save-dev mocha chai supertest\n\nEl archivo package.json debe contener un script para ejecutar las pruebas:
{\n "scripts": {\n "test:integration": "mocha test/integration/**/*.test.js --timeout 10000"\n }\n}\n\n3. Creación del entorno Docker para pruebas
\n\nEl archivo clave es docker-compose.test.yml. Describe los servicios necesarios para las pruebas.
version: '3.8'\n\nservices:\n app-test:\n build:\n context: .\n dockerfile: Dockerfile\n environment:\n - NODE_ENV=test\n - DB_HOST=postgres-test\n - DB_PORT=5432\n - DB_USER=test_user\n - DB_PASSWORD=test_pass\n - DB_NAME=test_db\n depends_on:\n postgres-test:\n condition: service_healthy\n command: ["npm", "run", "test:integration"]\n\n postgres-test:\n image: postgres:15-alpine\n environment:\n POSTGRES_USER: test_user\n POSTGRES_PASSWORD: test_