Guía integral de pruebas unitarias JavaScript 2026

Probablemente estás en una de dos situaciones ahora mismo. O tu proyecto de JavaScript tiene casi ninguna prueba y cada refactor se siente arriesgado, o ya tienes pruebas y la mitad de ellas son lentas, frágiles y difíciles de confiar.

Que empeora en Capacitor y Electron aplicaciones. Una característica simple puede afectar la lógica empresarial compartida, las API del navegador, los plugins nativos, los archivos locales, la comunicación interprocesos y los servicios remotos en el mismo flujo. Si pruebas esas piezas de manera incorrecta, tu conjunto de pruebas se convierte en un laberinto de dependencias falsas. Si las pruebas de manera correcta, obtienes feedback rápido sobre la lógica que se rompe.

Las pruebas unitarias JavaScript efectivas no comienzan con la sintaxis de los matchers inteligentes. Comienza con un límite disciplinado: prueba la lógica pura directamente, aísla los efectos laterales y evita escribir pruebas que se derrumben en cuanto renames una función interna.

Contenido de la Tabla

Elige tu marco de pruebas de JavaScript
Configuración del proyecto y tu primer test
Dominar Mocks y Code asíncronos
Estrategias avanzadas para pruebas robustas
Pruebas para CI, Capacitor, y aplicaciones de Electron
Preguntas Frecuentes sobre la Prueba Unitaria de JavaScript

Elegir tu marco de pruebas de JavaScript

Un proyecto de JavaScript profesional necesita un verdadero ejecutor de pruebas. Los scripts ad hoc y las comprobaciones manuales en la consola no escalan cuando varios ingenieros tocan el mismo código base. Se necesita descubrimiento de pruebas, afirmaciones, manejo asíncrono, mocks y una forma de ejecutar todo consistentemente en desarrollo local y CI.

La guía actual se está convergiendo en una pequeña serie de opciones de mainstream. Jest, Mocha y Jasmine son repetidamente destacados como los marcos principales, con Jest a menudo destacado por su estructura de prueba integrada, afirmaciones, simulación y soporte asíncrono en un paquete, como se muestra en este lab de prueba de JavaScript de Pluralsight.

Una tabla de comparación que muestra los marcos de prueba de JavaScript populares, incluyendo Jest, Mocha, Cypress y Playwright.

Por qué un marco no es opcional

El primer error que cometen los equipos es tratar las pruebas unitarias como una actividad secundaria. Eso suele llevar a nombres de archivo inconsistentes, afirmaciones personalizadas que nadie recuerda y ayudantes que solo entiende una persona.

Un marco te da un lenguaje compartido:

Estructura de prueba con describe y test o it
Declaraciones con comparadores legibles
Hooks para la configuración y el desmontaje
Apoyo asíncrono para promesas y temporizadores
Herramientas de simulación para dependencias externas

Si su equipo también necesita una visión más amplia de la automatización de pruebas más allá del trabajo a nivel de unidad, Capgo tiene una útil visión general de la prueba automatizada en los flujos de entrega de aplicaciones.

Jest vs Mocha a la vista

Jest y Mocha representan dos filosofías diferentes.

Jest es la opción todo en uno. Lleva la mayoría de lo que las equipos necesitan desde el primer día.
Mocha es más modular. Te da un ejecutor y espera que assembles el resto de la pila.

Característica	Jest	Mocha
Complejidad de configuración	Menor para la mayoría de los equipos	Más alta porque normalmente agregas bibliotecas de afirmaciones y simulación
Afirmaciones	Integrado en	Normalmente se combina con otra biblioteca
Simulacro	Integrado en	Normalmente se combina con otra biblioteca
Pruebas asíncronas	Integrado y sencillo	Soportado, pero depende más de la configuración circundante
Flujo de cobertura	Comúnmente integrado en el mismo conjunto de herramientas	A menudo más descompuesto
Mejor ajuste	Proyectos nuevos, equipos que quieren consistencia	Estacks legados, equipos que quieren control modular

Regla práctica: Si su equipo tiene que preguntar cuál es la biblioteca de afirmaciones y cuál es la biblioteca de simulación que combinar con el ejecutor, probablemente querrá Jest.

Para la mayoría de los proyectos modernos, elijo Jest a menos que el código base ya tenga razones fuertes para quedarse en Mocha. Esa recomendación se vuelve más fuerte cuando la aplicación incluye Capacitor or Electronporque esos proyectos ya tienen suficientes partes en movimiento. Reducir la dispersión de herramientas de prueba paga rápidamente.

En servicios de Node.js más antiguos o en códigobases de larga vida donde el ecosistema alrededor de ella ya está asentado, Mocha todavía tiene sentido. Pero para un ingeniero de nivel medio que está configurando un conjunto robusto desde cero, Jest suele eliminar más fricciones de las que crea.

Un importante nota de alcance. Cypress y Playwright son herramientas excelentes, pero resuelven un problema diferente. Son mejores para las pruebas de nivel de navegador y de fin de carrera, no para el rápido bucle interior donde las pruebas de unidad deben vivir.

Configuración del Proyecto y Tu Primer Test

Un setup de pruebas limpio debe ser aburrido. Si agregar el primer test siente complicado, el conjunto probablemente no se mantendrá saludable.

Un hombre con gafas trabajando en un proyecto de programación en una laptop en una mesa de madera.

Una configuración de Jest simple

Comienza con un proyecto de JavaScript que ya tiene un package.jsonEntonces agrega Jest como una dependencia de desarrollo y configura un script de prueba.

{
  "scripts": {
    "test": "jest"
  }
}

Eso es suficiente para muchos proyectos. Puedes agregar más configuración más adelante si tu sistema de módulos, transpilación o estructura de monorepo lo requiere.

Si estás construyendo una aplicación local Capacitor y quieres que tu entorno de desarrollo esté en orden antes de agregar pruebas alrededor de la lógica compartida, Capgo's guía para configurando un entorno local Capacitor es un compañero práctico.

Escriba el test antes de la code

El patrón de prueba primero no es solo una preferencia personal. La Oficina de Protección Financiera del Consumidor de los Estados Unidos recomienda explícitamente escribir el test primero, organizar los tests con describe y it, y definir las comprobaciones alrededor expect(...) de las afirmaciones en su guía de pruebas unitarias de JavaScript.

Eso importa porque el test-first cambia cómo diseñan code. Las funciones tienden a volverse más pequeñas, las dependencias se vuelven más visibles y los efectos laterales dejan de filtrarse en la lógica que debe permanecer pura.

Aquí hay un ejemplo mínimo:

// math.js
function addTax(amount, rate) {
  return amount + amount * rate;
}

module.exports = { addTax };

// math.test.js
const { addTax } = require('./math');

describe('addTax', () => {
  it('returns the amount with the tax applied', () => {
    expect(addTax(100, 0.2)).toBe(120);
  });
});

Use Arrange Act Assert cada vez

El Arreglar, Actuar, Asentar El patrón mantiene las pruebas legibles, incluso cuando crecen más complejas.

Arreglar la entrada y cualquier configuración necesaria.
Actuar llamando a la función.
Asentar en el resultado.

Aplicado a un ayudante de validación:

function isSupportedPlatform(platform) {
  return ['ios', 'android', 'web', 'desktop'].includes(platform);
}

describe('isSupportedPlatform', () => {
  it('returns true for ios', () => {
    // Arrange
    const platform = 'ios';

    // Act
    const result = isSupportedPlatform(platform);

    // Assert
    expect(result).toBe(true);
  });
});

Las pruebas pequeñas envejecen bien. Una prueba debe responder normalmente a una pregunta, no narrar un flujo de trabajo completo.

Para proyectos de Capacitor y Electron, esa disciplina importa más porque tu lógica pura a menudo se encuentra junto a la integración nativa o de escritorio code. Mantén la regla de negocio probable sin el tiempo de ejecución de la plataforma, y tu primera prueba no será tu última útil.

Maestría en Mocks y Asíncronos Code

La mayoría de los errores en la aplicación code no provienen de sumar dos números. Proceden de code que se extiende más allá de sí mismo: solicitudes de red, archivos, APIs de plugins, temporizadores, canales de IPC, capas de almacenamiento.

Donde la simulación te da control sobre la frontera para que el test pueda centrarse en la toma de decisiones de tu code.

Un diagrama de tablero que ilustra una arquitectura de microservicios con APIs, almacenes de datos, servicios externos y flujo de datos impulsado por eventos.

No simulacros de fronteras, no todo

La guía de testeo sostenible enfatiza la cobertura de un comportamiento y Una fuerte afirmación por pruebay también advierte que el uso excesivo de mocks hace que los tests sean frágiles y estrechamente acoplados a detalles de implementación, como se resume en este Artículo de TestRail sobre pruebas unitarias mantenibles.

That warning matters a lot in JavaScript. Teams often start by mocking every imported module and end up testing whether functions call other functions in the “correct” order, instead of testing real behavior.

Bad target for a mock-heavy test:

si el ayudante A llamó al ayudante B
si el servicio C llamó al serializador D
si una función interna privada se ejecutó dos veces

Mejor objetivo:

qué devolvió la función
si manejo correctamente una dependencia fallida
si transformó los datos en la forma esperada

Un mejor patrón para Capacitor y Electron code

En aplicaciones móviles y de escritorio, prefiero una capa de envoltura alrededor de las API nativas o de plataforma. Luego, los tests unitarios simulan la capa, no la plataforma en sí.

Estructura de ejemplo:

// cameraGateway.js
async function getPhoto(cameraPlugin) {
  return cameraPlugin.getPhoto();
}

module.exports = { getPhoto };

// profilePhotoService.js
async function loadProfilePhoto(cameraGateway) {
  const photo = await cameraGateway.getPhoto();
  return { path: photo.path, ready: true };
}

module.exports = { loadProfilePhoto };

// profilePhotoService.test.js
const { loadProfilePhoto } = require('./profilePhotoService');

test('returns mapped photo data', async () => {
  const fakeCameraGateway = {
    getPhoto: jest.fn().mockResolvedValue({ path: '/tmp/pic.jpg' })
  };

  const result = await loadProfilePhoto(fakeCameraGateway);

  expect(result).toEqual({ path: '/tmp/pic.jpg', ready: true });
});

Este patrón funciona también para Electron. Envuelve ipcRenderer, acceso a archivos, o integraciones de consola detrás de un adaptador delgado. Los tests unitarios golpean la capa de servicio, no la ejecución directamente.

Para equipos que prueban la lógica de lanzamiento y los caminos de actualización en aplicaciones Capacitor, Capgo tiene una guía relevante sobre Prueba de actualizaciones Capacitor OTA con escenarios de simulación.

Un recorrido rápido puede ayudar si su equipo todavía está normalizando el estilo de prueba asíncrono:

Prueba de flujos asíncronos sin inestabilidad

Utiliza async/await en pruebas cuando el code bajo prueba devuelve una promesa. Es más claro que los patrones pesados en callbacks y más fácil de depurar.

async function fetchProfile(api) {
  const response = await api.getUser();
  return response.name;
}

test('returns the user name from the API response', async () => {
  const api = {
    getUser: jest.fn().mockResolvedValue({ name: 'Ava' })
  };

  const result = await fetchProfile(api);

  expect(result).toBe('Ava');
});

También prueba el camino de falla:

test('throws when the API request fails', async () => {
  const api = {
    getUser: jest.fn().mockRejectedValue(new Error('network failed'))
  };

  await expect(fetchProfile(api)).rejects.toThrow('network failed');
});

Prueba tanto el camino feliz como el camino feo. En producción, el camino feo es el que los usuarios recuerdan.

Estrategias Avanzadas para Pruebas Robustas

Una suite de pruebas se vuelve útil cuando sigue siendo útil después de los code cambios. Eso es más difícil que escribir una pila de pruebas que pasan.

Un diagrama que ilustra estrategias para construir software robusto mediante una cobertura de pruebas integral y suites de pruebas mantenibles.

Utiliza la prueba de división como presupuesto

Una guía práctica recomienda un 70/20/10 dividido en pruebas unitarias, de integración y de fin de ciclocon unit tests que proporcionan la retroalimentación más rápida y las fallas más estables. La misma guía indica que un conjunto de unit tests completo debería idealmente terminar en menos de 10 segundosy las comprobaciones pre-commit deben permanecer menos de 5 segundosde acuerdo a esto Guía de pruebas de OpenReplay.

I treat that as a budgeting tool, not a religion. If most of your effort goes into end-to-end tests, your team will wait too long for feedback. If everything is unit-only, you’ll miss real system boundaries.

Para una aplicación Capacitor o Electron, un equilibrio saludable suele ser así.

Pruebas unitarias para la lógica de precios, reglas de permisos, serialización, elegibilidad de actualizaciones, banderas de características y transformaciones de estado
Pruebas de integración para adaptadores de almacenamiento, envolturas de plugins y contratos de IPC
Pruebas E2E para unos pocos viajes críticos como inicio de sesión, flujo de compra, sincronización o solicitudes de actualización

La cobertura es una linterna, no un objetivo

Los informes de cobertura son útiles cuando ayudan a identificar ramas no probadas en lógica importante. Se vuelven perjudiciales cuando los equipos persiguen porcentajes de cobertura por su propio interés.

A login validator with thoughtful edge-case tests gives more value than a covered file full of trivial assertions. That’s especially true for input-heavy code such as forms, parsers, date logic, and permission checks. If your team is tightening quality around validation-heavy UI, this guide on dominando la validación de formularios frontend Es una buena complementación a la estrategia de pruebas unitarias.

Pruebas de comportamiento resisten los refactores

Un conjunto confiable debería permitir que refactores internos sin reescribir la mitad de las pruebas. La forma más fácil de lograrlo es afirmar comportamiento observable en lugar de detalles de implementación.

Uso de casos que se sostienen bien:

condiciones de límites como entrada vacía, valores nulos, tipos inválidos y cadenas de texto demasiado grandes
resultados del dominio como “se rechazan devoluciones por falta de permiso”
transiciones de estado como “marca actualización como pendiente después de validar metadatos de descarga”

Uso de casos que a menudo se descomponen:

inspeccionar llamadas de ayuda internas
asegurar la secuencia de métodos privados
mockeando cada capa en la cadena de llamadas

Para equipos de aplicaciones que construyen procesos de lanzamiento disciplinados, el artículo de Capgo la calidad de la aplicación es útil porque conecta el trabajo de prueba con la canalización de liberación más amplia.

Pruebas para CI, Capacitor, y aplicaciones de Electron

Una prueba que solo se ejecuta en la máquina de un desarrollador no es un seguro. Es un hábito local.

La CI convierte el trabajo de pruebas de unidades de JavaScript en infraestructura de equipo. Cada empuje, solicitud de revisión o rama de liberación puede ejercer los mismos comandos con las mismas expectativas. Esa consistencia importa aún más para los proyectos de Capacitor y Electron, donde el desplazamiento del entorno causa fallas sutiles.

Make CI the default execution path

Al menos, su CI debe instalar dependencias y ejecutar el conjunto de pruebas de unidades en cada conjunto de cambios. Mantenga el comando idéntico al desarrollo local cuando sea posible.

Un flujo de trabajo básico de GitHub Actions puede ser tan pequeño como esto:

name: test

on: [push, pull_request]

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

Es suficiente para capturar importaciones rotas, afirmaciones fallidas y suposiciones de plataforma accidentales antes de que lleguen a la principal.

Para equipos móviles que envían a través de pipelines automatizados, Capgo tiene una guía práctica Configurando CI/CD para aplicaciones Capacitor.

Pruebas de interacción del plugin Capacitor

La forma incorrecta de probar unidades de Capacitor code es extraer plugins nativos directamente en cada servicio. Esto acopla su conjunto de pruebas con la puente de plataforma.

El patrón mejor es una abstracción delgada:

// deviceStorage.js
async function saveFile(filesystem, path, data) {
  return filesystem.writeFile({ path, data });
}

module.exports = { saveFile };

// draftService.js
async function persistDraft(storage, draft) {
  await storage.save('draft.json', JSON.stringify(draft));
  return { saved: true };
}

module.exports = { persistDraft };

// draftService.test.js
const { persistDraft } = require('./draftService');

test('persists a serialized draft', async () => {
  const storage = {
    save: jest.fn().mockResolvedValue(undefined)
  };

  const result = await persistDraft(storage, { title: 'Hello' });

  expect(result).toEqual({ saved: true });
});

La misma idea se aplica a la acceso a la cámara, solicitudes de promoción biométrica, registro de tokens de empuje y estado de red. Mantenga las llamadas de plugin en adaptadores. Pruebe la lógica de la aplicación contra interfaces que controla.

Pruebas de unidad para Electron main renderer e IPC code

Electron apps have two important seams: proceso principal code y proceso de renderizado codeNo borre estas juntas en las pruebas.

Una configuración confiable separa generalmente:

Pruebas unitarias del renderizador Para modelos de vistas, estado, formateo y lógica empresarial en la interfaz de usuario
Pruebas unitarias del proceso principal para menús, operaciones de archivo y decisiones de ciclo de aplicación
Pruebas del contrato de IPC para la forma de mensaje y respuestas esperadas

Ejemplo de envoltura de IPC:

// ipcGateway.js
function sendSettings(ipcRenderer, payload) {
  ipcRenderer.send('settings:update', payload);
}

module.exports = { sendSettings };

// ipcGateway.test.js
const { sendSettings } = require('./ipcGateway');

test('sends settings update over ipc', () => {
  const ipcRenderer = { send: jest.fn() };

  sendSettings(ipcRenderer, { theme: 'dark' });

  expect(ipcRenderer.send).toHaveBeenCalledWith('settings:update', { theme: 'dark' });
});

Si cambias más tarde la implementación interna de un helper a otro, esta prueba sigue siendo válida porque verifica el comportamiento que importa. Ese es el estándar que deseas en escritorios y móviles code.

Preguntas Frecuentes sobre la Prueba Unitaria de JavaScript

¿Cuál es la diferencia entre las pruebas unitarias, de integración y E2E?

A prueba unitaria verifica una pequeña pieza de lógica de manera aislada. Un prueba de integración verifica si un par de componentes o servicios funcionan correctamente. Un prueba de fin a fin Revisa el flujo de la aplicación en ejecución.

Utilice pruebas unitarias para una confianza rápida en las reglas comerciales. Utilice pruebas de integración para grietas como almacenamiento, envolturas de plugins y IPC. Utilice pruebas E2E con moderación para los flujos de trabajo que se verían seriamente afectados si se rompieran.

¿Debemos aspirar a una cobertura completa

No. La cobertura completa puede llevar a los equipos hacia pruebas de baja valor.

La cobertura es útil cuando revela riesgos code que nadie ha ejercitado. No es útil cuando los ingenieros agregan afirmaciones superficiales solo para satisfacer una pizarra. Si su conjunto es frágil, más cobertura no lo salvará.

¿Cómo agregamos pruebas a un código existente

Comience donde ya ocurren cambios. No congele al equipo y anuncie una gran reescritura de la estrategia de pruebas.

Una secuencia práctica se parece a esto:

Proteja el code activo primero agregando pruebas a módulos que tocas durante el trabajo de características o correcciones de errores
Extraiga la lógica pura de archivos difíciles de probar para que las reglas comerciales puedan ser probadas sin ruido de marco o tiempo de ejecución
Agregue envolturas de costura alrededor de plugins nativos, clientes de red, llamadas al sistema de archivos y IPC de Electron
Rechace patrones frágiles cuando se introducen mocks. Orientación de Prácticas recomendadas de pruebas de JavaScript El objetivo no es la completitud inmediata. Es una mejora constante en los lugares donde las regresiones cuestan al equipo más

El objetivo no es la completitud inmediata. Es una mejora constante en los lugares donde las regresiones cuestan más al equipo.

Si su equipo envía Capacitor o Electron aplicaciones y necesita un proceso de liberación más limpio alrededor de los cambios de JavaScript, Capgo es una de las opciones para considerar. Proporciona actualizaciones en vivo para aplicaciones de CapacitorJS y Electron, con controles de despliegue y observabilidad, para que los equipos puedan combinar pruebas unitarias sólidas con un camino más seguro para enviar cambios en paquetes web sin tener que esperar a la revisión de la tienda para cada corrección.

Pruebas unitarias de JavaScript: Guía integral de 2026