Pruebas unitarias de JavaScript: Guía integral de 2026

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

Que empeora en Capacitor Electron Electron 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 el momento en que renombres una función interna.

Good unit tests JavaScript work doesn’t start with clever matcher syntax. It starts with a disciplined boundary: test pure logic directly, isolate side effects, and avoid writing tests that collapse the moment you rename an internal function.

Contenido de la Tabla

• Por qué un marco no es opcional
  • Jest vs Mocha a la vista
  • Jest vs Mocha a vistazo
  • Lo que recomiendo para la mayoría de los equipos
• Configuración del proyecto y tu primer test
  • Una configuración de Jest simple
  • Escribe el test antes de la code
  • Utiliza Arrange Act Assert cada vez
• Dominar Mocks y Asincronos Code
  • Simula límites, no todo
  • Un mejor patrón para Capacitor y Electron code
  • Pruebas de flujo asincrono sin flaqueza
• Estrategias avanzadas para pruebas robustas
  • Utiliza la división de testing como presupuesto
  • La cobertura es una linterna, no un objetivo
  • Pruebas de comportamiento resisten los refactorizaciones
• Pruebas para CI, Capacitor, y aplicaciones de Electron
  • Hacer que CI sea el camino de ejecución por defecto
  • Pruebas de interacción del plugin Capacitor
  • Pruebas de Electron main renderer e IPC code
• Preguntas Frecuentes sobre la Prueba de Unidad de JavaScript
  • ¿Cuál es la diferencia entre pruebas de unidad, integración y E2E?
  • ¿Debemos aspirar a una cobertura completa?
  • ¿Cómo agregar pruebas a un código existente?

Elegir tu marco de prueba de JavaScript

Un proyecto de JavaScript profesional necesita un verdadero ejecutor de pruebas. Los scripts ad hoc y las comprobaciones manuales de la consola no escalan una vez que varios ingenieros tocan el mismo código base. Necesitas descubrimiento de pruebas, afirmaciones, manejo asíncrono, mocks y una forma de ejecutar todo de manera consistente 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 frecuentemente destacado por su estructura de pruebas integrada, afirmaciones, simulación y soporte asíncrono en un solo paquete, como se muestra en este lab de prueba de JavaScript de Pluralsight.

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, declaraciones 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 desmantelamiento
• 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 automated testing in app delivery workflows.

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.

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 para pair con el ejecutor, probablemente quieren 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ódigobase ya tenga razones fuertes para quedarse en Mocha. Esa recomendación se vuelve más fuerte cuando la aplicación incluye Capacitor or Electronporque Electron ya tiene suficientes partes en movimiento. Reducir la dispersión de herramientas de pruebas 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.

Nota importante de alcance. Cypress y Playwright son herramientas excelentes, pero resuelven un problema diferente. Son mejores para las pruebas de nivel de navegador y fin a fin, no para el rápido bucle interior donde las pruebas unitarias de JavaScript deberían vivir.

Configuración del Proyecto y Tu Primer Test

Un setup 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.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 Capacitor localmente y deseas tener tu entorno de desarrollo organizado antes de agregar pruebas alrededor de la lógica compartida, el manual de Capgo Configurando un entorno local Capacitor es un compañero práctico.

Escriba el test antes de code

No es solo una cuestión de preferencia personal. La guía de JavaScript de la Oficina de Protección Financiera del Consumidor de los EE. UU. recomienda explícitamente escribir el test primero, organizar los tests con describe y it, y configurar los controles alrededor expect(...) assertiones en ella declaraciones de aserción en su.

That matters because test-first changes how you design code. Functions tend to become smaller, dependencies become more visible, and side effects stop leaking into logic that should stay pure.

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

Aquí hay un ejemplo mínimo:

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

1. Arreglar la entrada y cualquier configuración necesaria.
2. Actuar llamando a la función.
3. 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.

Maestrando 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.

Eso es donde ayuda el mocking. Te da control sobre la frontera para que la prueba se centre en la toma de decisiones de tu code.

No simulacros, solo límites

La guía de pruebas mantenibles 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í misma.

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 ipcRendererAcceso a archivos, o integraciones de consola detrás de un adaptador delgado. Las pruebas unitarias golpean la capa de servicio, no la ejecución directamente.

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

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

Prueba de flujos asíncronos sin flaquezas

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.

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 a fincon feedback instantáneo y fallas más estables. La misma guía recomienda que un conjunto de pruebas unitarias completo debería terminar en menos de 10 segundos, y las comprobaciones pre-commit deberían quedarse menos de 5 segundosde acuerdo con 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 verse 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 refactorizaciones

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

Casos de uso que se sostienen bien:

• Condiciones de límite valores nulos, tipos inválidos y cadenas de texto muy largas
• Resultados del dominio como “se deniegan devoluciones por falta de permiso”
• Transiciones de estado como “marca la actualización como pendiente después de validar los metadatos de descarga”

Casos de uso 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 pipelina de lanzamiento más amplia.

Pruebas para CI, Capacitor, y aplicaciones de Electron

Una prueba que solo se ejecuta en una máquina del desarrollador no es un seguro. Es una costumbre 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 lanzamiento 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 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 a la 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 accidental antes de que lleguen a la producción.

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

Pruebas de interacción del plugin Capacitor

La forma incorrecta de probar unidades de Capacitor code es sacar directamente los plugins nativos 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 code del main renderer y IPC de Electron

Electron apps have two important seams: proceso principal code y proceso de renderizado code. No las confunda en las pruebas.

Una configuración confiable separa generalmente:

• Pruebas unitarias del renderizador Para modelos de vista, estado, formateo y lógica comercial 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 del mensaje y las 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 la implementación interna de un helper a otro más adelante, 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 de Unidades de JavaScript

¿Cuál es la diferencia entre pruebas unitarias e integrales y pruebas 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 realiza un recorrido del usuario a través 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 resultarían muy dañados 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 suceden 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 prueba de JavaScript El objetivo no es la completitud inmediata. Es una mejora constante en los lugares donde las regresiones cuestan más al equipo

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 Electrón aplicaciones y necesita un proceso de lanzamiento más limpio alrededor de los cambios de JavaScript. Capgo Es una opción para considerar. Proporciona actualizaciones en vivo para aplicaciones de CapacitorJS y Electron, con controles de rollout y observabilidad, por lo que los equipos pueden 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.