Conceptos básicos de las pruebas

10 ejemplos para empezar con las pruebas: 7 básicos y 3 intermedios.

Requisitos previos

• Node.js 24.18.0 con node:test y node:assert integrados.
• Servicio TypeScript con patrón de exportación createApp().
• Opcional: npm install -D tsx supertest @types/supertest para pruebas de integración HTTP.

Ejemplos básicos

1. Pirámide de pruebas para APIs HTTP

Equilibra las pruebas unitarias rápidas con menos pruebas de integración y E2E.

        / E2E \          pocas - rutas críticas del usuario
       / contrato \      acuerdos consumidor-proveedor
      / integración \    HTTP + DB con Testcontainers
     /    pruebas unitarias  \  muchas - lógica pura, manejadores simulados

• La mayoría de las pruebas deben ser a nivel unitario (milisegundos cada una).
• Las pruebas de integración demuestran el cableado; las E2E demuestran el entorno desplegado.
• Las pruebas de contrato son importantes cuando múltiples servicios evolucionan APIs de forma independiente.

2. Prueba de humo node:test

Ejecutor de pruebas sin dependencias integrado en Node 24.

import assert from "node:assert/strict";
import { describe, it } from "node:test";
 
import { calculateTax } from "../src/billing/tax.js";
 
describe("calculateTax", () => {
  it("aplica la tasa al subtotal", () => {
    assert.equal(calculateTax(100, 0.2), 20);
  });
});

node --import tsx --test test/tax.test.ts

• No se necesita Jest para funciones puras.
• node:assert/strict usa semántica ===.

Relacionado: node:test y node:assert - guía completa del ejecutor

3. Exportar createApp para pruebas HTTP

Separa la fábrica de servidores de listen para Supertest.

// src/app.ts
import express from "express";
 
export function createApp() {
  const app = express();
  app.get("/health", (_req, res) => res.json({ ok: true }));
  return app;
}

• Las pruebas importan createApp() sin vincular un puerto.
• server.ts de producción llama a createApp().listen(...).
• El patrón funciona para Express 5 y Fastify con app.ready().

Relacionado: Supertest e integración HTTP - HTTP en proceso

4. Estructura Arrange-Act-Assert

Las pruebas legibles documentan el comportamiento esperado.

it("devuelve 404 para una factura desconocida", async () => {
  // Arrange (Preparar)
  const app = createApp();
  // Act (Actuar)
  const res = await request(app).get("/invoices/missing");
  // Assert (Comprobar)
  assert.equal(res.status, 404);
});

• Un enfoque de aserción lógica por prueba cuando sea posible.
• Nombra las pruebas como comportamiento: devuelve 404 cuando ....
• Evita probar funciones privadas; prueba la API pública HTTP o del módulo.

5. Aislar pruebas con beforeEach

Restablece los mocks y el estado entre casos.

import { beforeEach, describe, it } from "node:test";
 
let cache: Map<string, string>;
 
beforeEach(() => {
  cache = new Map();
});

• Previene fallos dependientes del orden.
• Usa almacenes en memoria en pruebas unitarias; DB real solo en el conjunto de integración.

6. Script npm test

Único punto de entrada para local y CI.

{
  "scripts": {
    "test": "node --import tsx --test",
    "test:unit": "node --import tsx --test test/unit",
    "test:integration": "node --import tsx --test test/integration"
  }
}

• Divide los conjuntos cuando la integración necesita servicios Docker.
• CI ejecuta ambos; los desarrolladores ejecutan el bucle unitario durante el TDD.

7. Variables de entorno de prueba

Usa .env.test o valores predeterminados en línea para la configuración solo de prueba.

process.env.DATABASE_URL ??= "postgres://localhost:5432/billing_test";
process.env.LOG_LEVEL = "silent";

• Nunca apuntes las pruebas a bases de datos de producción.
• LOG_LEVEL=silent mantiene la salida de la prueba legible.

Ejemplos intermedios

8. Prueba de integración con Postgres real

Testcontainers inicia una DB efímera en CI.

// test/integration/invoices.test.ts - ubicación conceptual
// Consulta la página de Testcontainers para la configuración completa

• Ejecuta en un trabajo separado con Docker disponible.
• Una migración de esquema por suite; trunca las tablas entre pruebas.

Relacionado: Testcontainers - Postgres/Redis en CI

9. Prueba de contrato entre servicios

El consumidor define la forma de respuesta esperada del proveedor.

// Prueba de pacto del consumidor - el proveedor debe coincidir con el contrato publicado
// Consulta la página de Contrato y Pacto

• Detecta cambios de API que rompen la compatibilidad antes del despliegue.
• Ejecuta en el CI del proveedor verificando todos los pactos del consumidor.

Relacionado: Pruebas de contrato y pacto - límites de microservicios

10. Prueba de carga antes del lanzamiento

Latencia de referencia y tasa de error bajo el RPS esperado.

k6 run scripts/load/smoke.js

• No es un reemplazo de las pruebas unitarias; valida las suposiciones de SLO.
• Ejecuta contra el entorno de staging con un volumen de datos similar al de producción.

Relacionado: Pruebas de carga con k6/Artillery - RPS de referencia

Versiones de la pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.