Las pruebas end-to-end con Supertest te permiten automatizar lo que normalmente harías manualmente en Insomnia o Postman: enviar un request a un endpoint y validar su respuesta de forma programática. Aprenderás a montar un servidor en Express, lanzarle solicitudes desde código y verificar status codes, headers y body como un profesional del backend en Node.js.

¿Qué son las pruebas end-to-end y en qué se parecen a Postman?

Las pruebas end-to-end ejecutan un request real contra tu servidor y analizan la respuesta completa, igual que cuando pegas una URL en Insomnia, presionas send y revisas el resultado.

La diferencia está en el alcance y la automatización. En lugar de hacer clic una y otra vez para validar un solo caso de uso, escribes código que cubre múltiples escenarios para cada endpoint. Por ejemplo, al crear un producto no solo pruebas el caso feliz: también validas variantes, errores y formatos.

¿Qué hace una prueba end-to-end? Envía un request a un endpoint real, recibe la respuesta del servidor y verifica de forma programática que el status code, los headers y el body coincidan con lo esperado.

Lo interesante es que estas pruebas no se quedan en un solo aspecto. Puedes verificar si el servidor se conectó, si devolvió la información correcta, si validó los DTO y si respondió con el status code apropiado. Todo en un solo flujo automatizado.

¿Cómo instalar Supertest y preparar el entorno?

La herramienta más usada para pruebas end-to-end en Node.js es Supertest, y se instala como dependencia de desarrollo igual que Jest [3:48].

El flujo de instalación es directo:

• Abre tu terminal en la raíz del proyecto.
• Ejecuta el comando de instalación de Supertest como devDependency.
• Crea un archivo nuevo llamado app.endtoend.js para tu primera prueba.

Una vez instalada, importas la librería con require y la guardas en una constante llamada request. Esta constante será la encargada de emular, o más bien ejecutar, los requests reales contra tu aplicación.

¿Cómo escribir tu primera prueba con Supertest y Express?

Dentro del archivo de prueba, primero montas una aplicación pequeña en Express con un endpoint que responda algo concreto, y después la pasas a Supertest para atacarla [5:30].

El ejemplo mínimo se ve así:

javascript const request = require('supertest'); const express = require('express');

const app = express();

app.get('/hello', (req, res) => { res.status(200).json({ name: 'Nico' }); });

app.listen(9000);

const api = request(app);

describe('Pruebas for app', () => { describe('GET /hello', () => { it('should return a response', async () => { const response = await api.get('/hello'); expect(response).toBeTruthy(); }); }); });

Fíjate en lo que pasa aquí. Creas la app, defines un endpoint /hello, la pones a escuchar en el puerto 9000 y le pasas la instancia a request. A partir de ese momento, api.get('/hello') ejecuta una solicitud real y guarda todo el detalle en response.

El matcher toBeTruthy confirma que la respuesta exista, es decir, que no sea null ni undefined. Es la validación más básica, pero suficiente para arrancar.

¿Qué puedes validar dentro del response?

El objeto response que devuelve Supertest contiene mucha más información de la que parece, y ahí está la riqueza de estas pruebas.

Entre las validaciones más comunes están:

• Status code: expect(response.statusCode).toEqual(200) para confirmar el código HTTP esperado.
• Body: expect(response.body.name).toEqual('Nico') para revisar el contenido del JSON devuelto.
• Headers: expect(response.headers['content-type']).toMatch(/json/) para verificar el formato de la respuesta.

¿Qué validar en una prueba end-to-end? El status code, el contenido del body y los headers como content-type. Con esos tres puntos cubres la mayor parte de los contratos que tu API debe cumplir.

Cuando ejecutas npm run test:endtoend con todas las aserciones bien escritas, Jest reporta que cada spec pasó. Si cambias el valor esperado, por ejemplo escribir 201 cuando el endpoint devuelve 200, la prueba falla y te muestra exactamente qué aserción rompió el contrato.

¿Por qué aparece el aviso de operación asíncrona sin terminar?

Al correr las pruebas, Jest puede mostrar un mensaje alarmante avisando que una operación asíncrona no ha parado y que la terminal queda colgada [13:20].

Esto sucede porque app.listen(9000) deja un proceso abierto escuchando en ese puerto, y Jest no lo cierra automáticamente al terminar las aserciones. Para salir, toca matar el proceso manualmente con Control C o Control Z, lo cual no es ideal en un flujo de integración continua.

Es un detalle importante porque indica que el servidor sigue vivo después de las pruebas, consumiendo recursos y bloqueando la terminal. La solución correcta pasa por manejar el ciclo de vida del servidor dentro de la prueba, algo que se aborda en la siguiente clase.

¿Ya intentaste escribir tu primera prueba end-to-end? Cuéntame en los comentarios qué endpoint validaste primero y qué matcher te resultó más útil.