Pruebas Unitarias JavaScript: Guía Integral 2026

Probablemente estás en una de dos situaciones en este momento. 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 extrañamente difíciles de confiar.

Eso empeora en Capacitor y aplicaciones de Electron. 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. Unit Tests JavaScript: Comprehensive 2026 Guide

Las pruebas unitarias de JavaScript no comienzan con una sintaxis de matcher inteligente. Comienzan 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.

Índice

• Elegir su marco de pruebas de JavaScript
  • Por qué un marco no es opcional
  • Jest vs Mocha a la vista
  • Lo que recomiendo para la mayoría de los equipos
• Configuración del proyecto y su primera prueba
  • Una configuración de Jest simple
  • Escriba la prueba antes de code
  • Utilice Arrange Act Assert cada vez
• Dominar mocks y Code asíncronos
  • Simule límites, no todo
  • Un patrón mejor para Capacitor y Electron code
  • Pruebas de flujo asíncrono sin inestabilidad
• Estrategias avanzadas para pruebas robustas
  • Utiliza la división de pruebas como un presupuesto
  • La cobertura es una linterna, no un objetivo
  • Las pruebas de comportamiento sobreviven a los refactores
• Pruebas para CI, Capacitor, y aplicaciones de Electron
  • Haz que CI sea el camino de ejecución por defecto
  • Pruebas de interacción del plugin Capacitor
  • Pruebas de Electron main renderer y IPC code
• Preguntas frecuentes sobre pruebas unitarias de JavaScript
  • ¿Cuál es la diferencia entre pruebas unitarias, de integración y E2E?
  • ¿Deberíamos aspirar a una cobertura completa
  • Cómo agregar pruebas a un códigobase existente

Elige tu marco de pruebas de JavaScript

Un proyecto de JavaScript profesional necesita un verdadero ejecutor de pruebas. Los scripts ad hoc y las comprobaciones de consola manuales no escalan una vez que varios ingenieros tocan el mismo códigobase. Necesitas descubrimiento de pruebas, afirmaciones, manejo de sincronización asíncrona, mocks y una forma de ejecutar todo de manera consistente en desarrollo local y CI.

La guía actual sigue convergiendo en un pequeño conjunto de opciones principales. Jest, Mocha y Jasmine son repetidamente destacados como los marcos principales, con Jest que a menudo se destaca por su estructura de prueba integrada, afirmaciones, simulación y soporte asíncrono en un paquete, como se muestra en este lab de pruebas de JavaScript de Pluralsight.

¿Por qué un marco no es opcional

The first mistake teams make is treating unit tests as a side activity. That usually leads to inconsistent file naming, custom assertions nobody remembers, and helpers that only one person understands.

Un marco te da un lenguaje compartido:

• Estructura de prueba con describe y test o it
• Declaraciones de verificación con comparadores legibles
• Hooks para configuración y desmontaje
• Compatibilidad asíncrona 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 pruebas automatizadas en flujos de trabajo 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 los 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.

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 se deben combinar con el ejecutor, probablemente querrá Jest.

Lo que recomiendo para la mayoría de los equipos

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

Mocha todavía tiene sentido en servicios de Node.js más antiguos o en bases de código vivas donde el ecosistema alrededor de ella ya está asentado. 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 comprobaciones de nivel de navegador y finales a fin, no para el rápido bucle interior donde los tests unitarios deberían vivir.

Configuración del Proyecto y Tu Primer Test

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

Una configuración de Jest simple

Comienza con un proyecto de JavaScript que ya tiene un package.json. Luego, agrega Jest como 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 Capacitor localmente 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.

Escribe la prueba antes de la code

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

Importa porque los cambios de prueba primero cambian 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 mantenerse pura.

Un ejemplo mínimo es:

// 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);
  });
});

Usen Arrange Act Assert cada vez

La patrón de Arrange, Act, Assert mantiene las pruebas legibles, incluso cuando se vuelven más complejas.

1. Arregle la entrada y cualquier configuración necesaria.
2. Actúe llamando a la función.
3. Asserte On 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 Capacitor y proyectos de 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 la plataforma de tiempo de ejecución, y tu primera prueba no será tu última útil.

Maestría en Mocks y Asincronía Code

La mayoría de los errores en la aplicación code no provienen de sumar dos números. Proviene 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.

Es ahí donde ayuda Mock. Te da control sobre la frontera para que la prueba pueda centrarse en la toma de decisiones de tu code.

Mockea las fronteras, no todo

La guía de pruebas sostenibles enfatiza cobertura de un comportamiento y una afirmación fuerte por pruebay también advierte que el uso excesivo de mocks hace que las pruebas sean frágiles y estén muy acopladas a los detalles de la implementación, como se resume en este artículo de TestRail sobre pruebas unitarias mantenibles.

Importa mucho esa advertencia en JavaScript. Los equipos suelen empezar por mockear cada módulo importado y terminan probando si las funciones llaman a otras funciones en el ‘orden correcto’, en lugar de probar el comportamiento real.

Objetivo poco adecuado para una prueba pesada en mocks:

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

Objetivo mejor:

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

Un patrón mejor para Capacitor y Electron code

En aplicaciones móviles y de escritorio, prefiero una capa de envoltura alrededor de APIs nativas o de plataforma. Luego, las pruebas unitarias 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 });
});

Ese patrón funciona también para Electron. Envuelve ipcRenderer, el acceso a archivos, o las integraciones de consola detrás de un adaptador delgado. Las pruebas unitarias golpean la capa de servicio, no la ejecución directamente.

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

Un walkthrough rápido ayuda si su equipo todavía está normalizando el estilo de prueba asíncrono:

Prueba de flujos asíncronos sin flaquezas

Utiliza async/await en las pruebas cuando el code bajo prueba devuelve una promesa. Es más claro que los patrones pesados en llamadas de retorno y es 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 usualmente el que recuerdan los usuarios.

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.

Utiliza la división de pruebas como un presupuesto

Una guía práctica recomienda una 70/20/10 división en pruebas unitarias, pruebas de integración y pruebas de fin de ciclo, con pruebas unitarias que proporcionan la retroalimentación más rápida y las fallas más estables. La misma guía dice que una suite de pruebas unitarias completa debería idealmente terminar en menos de 10 segundos, y los controles de pre-envío deberían quedarse menos de 5 segundossegún esto Guía de prueba de OpenReplay.

Trato eso como una herramienta de presupuestación, no como una religión. Si la mayor parte de tu esfuerzo se dirige a pruebas de fin a fin, tu equipo esperará demasiado tiempo para obtener feedback. Si todo es solo unitario, te perderás las verdaderas fronteras del sistema.

Para una aplicación Capacitor o Electron, un equilibrio saludable suele verse así:

• Pruebas unitarias para la lógica de precios, las reglas de permisos, la serialización, la elegibilidad de actualización, las banderas de características y las transformaciones de estado
• Pruebas de integración para adaptadores de almacenamiento, envolturas de plugins y contratos de IPC
• Pruebas de E2E para unos pocos viajes críticos como inicio de sesión, flujo de compra, sincronización o promt 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 un validador de inicio de sesión con pruebas de casos de borde pensativas ofrece más valor que un archivo completo de afirmaciones triviales. Eso es especialmente cierto para la entrada pesada code como formularios, parseadores, lógica de fechas y verificaciones de permisos. Si su equipo está ajustando la calidad alrededor de la validación intensiva de la interfaz de usuario, esta guía sobre dominio de la validación de formularios de frontend es una buena complemento a la estrategia de prueba de nivel de unidad.

Las pruebas de comportamiento sobreviven a los refactores

Un conjunto confiable debería permitirle refactorizar internos sin volver a escribir la mitad de las pruebas. La forma más fácil de llegar allí es asertar comportamiento observable en lugar de detalles de implementación.

Uso de casos que se sostienen bien:

• Condiciones de límite como entrada vacía, valores nulos, tipos inválidos y cadenas de texto muy grandes
• Resultados del dominio como 'devuelve denegado por falta de permiso'
• Transiciones de estado como “actualiza marcas como pendientes después de descargar metadatos validados”

Casos de uso que a menudo se descomponen:

• inspeccionar llamadas de ayuda internas
• afirmar la secuencia de métodos privados
• simular cada capa en la cadena de llamadas

Para equipos de aplicaciones que construyen procesos de liberación disciplinados, el artículo de Capgo sobre aseguramiento de calidad de aplicaciones es útil porque conecta el trabajo de pruebas con la pipelina de liberación más amplia.

Pruebas para CI, Capacitor, y aplicaciones de Electron

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

La CI convierte las pruebas unitarias en trabajo 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 Capacitor y proyectos de Electron, donde el desplazamiento de entorno causa fallas sutiles.

Establecer el CI como ruta de ejecución predeterminada

Al menos, su CI debería instalar dependencias y ejecutar el conjunto 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

Esto es suficiente para detectar importaciones rotas, afirmaciones fallidas y suposiciones de plataforma accidentales antes de que lleguen a main.

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

Probando interacciones de plugin Capacitor

La forma incorrecta de probar unidades de Capacitor code es tirar plugins nativos directamente a cada servicio. Esto acopla su conjunto de pruebas a 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 push y estado de red. Mantenga las llamadas de plugin en adaptadores. Pruebe la lógica de la aplicación contra interfaces que controla.

Probando code de IPC de renderizador principal de Electron

Las aplicaciones de Electron tienen dos importantes juntas: proceso principal code y proceso de renderizado code. No los borre en las pruebas.

Una configuración confiable suele separar:

• Pruebas unitarias del proceso de renderizado para modelos de vista, estado, formateo y lógica de negocio en la interfaz de usuario
• Pruebas unitarias del proceso principal para menús, operaciones de archivo y decisiones del ciclo de vida de la aplicación
• Pruebas del contrato de IPC para la forma de los mensajes y las respuestas esperadas

Ejemplo de envoltorio 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 más adelante cambias la implementación interna de un helper a otro, esta prueba sigue siendo válida porque verifica el comportamiento que importa. Eso es el estándar que deseas en escritorio y móvil code.

Preguntas Frecuentes Sobre Pruebas Unitarias de JavaScript

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

A una prueba unitaria verifica una pequeña pieza de lógica en aislamiento. Una prueba de integración verifica si un par de componentes o servicios funcionan correctamente juntos. Una prueba E2E ejercita un recorrido de usuario a través de la aplicación en ejecución.

Utiliza pruebas unitarias para una confianza rápida en las reglas comerciales. Utiliza pruebas de integración para junturas como almacenamiento, envolturas de plugins y IPC. Utiliza pruebas E2E con moderación para los flujos de trabajo que te harían daño si se rompieran.

¿Debemos aspirar a una cobertura completa

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

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

Cómo agregar pruebas a un código existente

Comienza 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:

• Protege primero los code activos agregando pruebas a módulos que tocas durante el trabajo de características o correcciones de errores
• Extrae 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
• Agrega envolturas de costura alrededor de plugins nativos, clientes de red, llamadas al sistema de archivos y IPC de Electron
• Rechaza patrones frágiles cuando se presentan mocks. La orientación de las mejores prácticas de pruebas de JavaScript es especialmente útil aquí porque destaca el problema a menudo pasado por alto de la sobremockificación y las pruebas frágiles que siguen

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

Si su equipo envía Capacitor o aplicaciones Electron y necesita un proceso de liberación más limpio alrededor de los cambios de JavaScript, __CAPGO_KEEP_0__ Capgo Escrito por