Prueba de unidades Jest: La guía práctica para equipos de JavaScript

Una versión de Capacitor puede pasar sus comprobaciones de fin a fin y aún enviar una factura de cobro rota, una bandera de característica estancada o una rama específica de plataforma. La falla suele comenzar antes: una prueba de unidad todavía refleja el comportamiento antiguo, un mock oculta una dependencia cambiada o los CI ejecutan un entorno diferente de la máquina del desarrollador. Por el momento en que el bug llega a un teléfono o una compilación de escritorio de Electron, el conjunto de pruebas ha proporcionado confianza sin proporcionar protección.

Por eso La prueba unitaria de Jest is best treated as a living workflow decision, not merely a runner command. The useful questions are practical: how quickly can a developer trust a failure, which boundaries should remain isolated, what coverage belongs in CI, and whether Jest still fits the project’s module system and feedback expectations? This guide focuses on those decisions across Node services, web applications, Capacitor projects, and Electron apps. For broader context on where automated checks fit into delivery, see automated testing in modern software workflows.

Contenido de la Tabla

• Why Jest Unit Testing Still Matters in 2026
• Instalación y configuración de Jest en diferentes entornos
  • Elige deliberadamente la transformación de TypeScript
  • Añade solo los shim de navegador que necesite tu code
• Writing Your First Reliable Unit Tests
• Estrategias de simulación que realmente escalan
  • Espías manuales para decisiones locales
  • Simulación de módulos para SDKs pesados
  • MSW para grietas HTTP
• Integración de Jest con CI y controles de cobertura
• Keeping Jest Unit Tests Trustworthy at Scale
  • Usar capas en lugar de obligar a Jest a controlar todo
• Marco de decisión y pasos siguientes para su equipo
  • Un reset práctico de 90 días

Why Jest Unit Testing Still Matters in 2026

Jest remains relevant because it solves more than assertion syntax. It gives teams a repeatable place to verify business logic, control dependency boundaries, enforce coverage expectations, and run checks before a mobile or desktop package reaches users. That workflow matters when the same JavaScript behavior runs in a browser shell, a Capacitor WebView, an Electron renderer, and a Node process with different platform APIs around it.

La adopción de Jest también tiene peso histórico. Facebook lo creó en 2011 para una reescritura de chat en JavaScript, lo abrió en 2014, y la Fundación OpenJS informó que había superado 38,000 GitHub estrellas y 17 millones de descargas semanales por 2022, aumentando a más de 43,000 estrellas y 21 millones de descargas semanales por 2024 (Historia del proyecto Jest de la Fundación OpenJS). Las cifras no demuestran que Jest es adecuado para cada nuevo repositorio, pero explican por qué los equipos a menudo heredan un ecosistema maduro, convenciones familiares y una gran cantidad de ejemplos existentes.

Skipping unit tests in favor of end-to-end coverage looks cheaper until every small failure requires a full application launch, device setup, network path, and platform-specific diagnosis. E2E tests are valuable for release-critical journeys. They’re a poor substitute for fast, focused checks around tax calculations, update manifests, permission decisions, storage adapters, and error mapping.

Regla práctica: Mantén Jest cuando su ecosistema reduce el riesgo de migración y tu conjunto de pruebas proporciona a los desarrolladores feedback confiable. Considera otro ejecutor cuando el ejecutor mismo se ha convertido en la botella diaria.

El resto de esta guía sigue ese flujo de trabajo. Configurarás Jest en diferentes entornos, escribirás pruebas enfocadas en el comportamiento, elegirás mocks que sigan siendo mantenibles, conectarás comprobaciones a CI y cobertura, reducirás la flacidez a gran escala y tomarás una decisión deliberada de mantener o cambiar.

Instalación y Configuración de Jest en Entornos Diferentes

Start with the smallest configuration that matches the runtime. A Node service usually needs Jest’s default environment and a test script. A browser-facing Capacitor or Electron module needs DOM-like globals, while TypeScript adds a transformation decision that can affect debugging, module compatibility, and startup behavior.

Para un proyecto de Node puro, inicialice el paquete y instale Jest como una dependencia de desarrollo:

npm init -y
npm install --save-dev jest
npx jest --init

La configuración generada es un punto de partida, no un veredicto de diseño. Revisa el entorno de prueba, las transformaciones, los alias de módulos y los archivos de configuración antes de comprometerlo.

Elige el transformador de TypeScript de manera deliberada

ts-jest es conveniente cuando el repositorio ya depende del comportamiento del compilador de TypeScript y los desarrolladores quieren diagnósticos familiares. @swc/jest es a menudo atractivo cuando la velocidad de transpilación importa y el control de tipos ya se ejecuta como un comando separado. Ninguna opción reemplaza un controlador de tipos, y los paquetes pesados en ESM pueden requerir configuración adicional independientemente del transformador.

A configuración de TypeScript utilizando ts-jest Puede verse así:

import type { Config } from 'jest'

const config: Config = {
  preset: 'ts-jest',
  testEnvironment: 'node',
  setupFilesAfterEnv: ['<rootDir>/jest.setup.ts'],
  clearMocks: true,
  collectCoverageFrom: ['src/**/*.{ts,tsx}'],
}

export default config

Para repositorios de JavaScript o mezclados basados en Babel, mantenga el archivo Babel explícito:

module.exports = {
  presets: [
    ['@babel/preset-env', { targets: { node: 'current' } }],
    '@babel/preset-typescript',
  ],
}

Añada solo los shim de navegador que necesita su code

Capacitor y pruebas de Electron importan frecuentemente code que espera window.matchMedia o IntersectionObserverUn archivo de configuración puede proporcionar simas controlados sin fingir que Jest es un dispositivo real o una caja de escritorio.

Object.defineProperty(window, 'matchMedia', {
  writable: true,
  value: (query: string) => ({
    matches: false,
    media: query,
    onchange: null,
    addListener: () => {},
    removeListener: () => {},
    addEventListener: () => {},
    removeEventListener: () => {},
    dispatchEvent: () => false,
  }),
})

class MockIntersectionObserver {
  observe() {}
  unobserve() {}
  disconnect() {}
}

Object.defineProperty(window, 'IntersectionObserver', {
  writable: true,
  value: MockIntersectionObserver,
})

Si una dependencia solo de ESM falla durante la recopilación, inspecciona transformIgnorePatterns and the package’s published format. Capacitor plugins can expose this problem when Jest ignores a dependency that still needs transformation. Jest’s newer releases have improved startup and memory behavior, but watch feedback can still trail ESM-focused alternatives in large projects (2026 Comparación de Jest y Vitesto experimentalVMModules as a compatibility lever to test deliberately, not a default switch.

For a JavaScript-focused setup walkthrough, use La guía de pruebas unitarias de Capgo para JavaScript. Finalice la instalación con un comando de verificación real:

npx jest --runInBand

Un test de humo exitoso confirma que Jest puede cargar el proyecto. No confirma que los gráficos de módulos de producción y de prueba se comporten de manera idéntica, por lo que mantenga un test de importación de ESM, DOM y plugin donde sea relevante.

Writing Your First Reliable Unit Tests

Una prueba unitaria útil describe un comportamiento observable en un contexto controlado. Arregla, Actúa, Aserta Mantener ese propósito visible: prepara los inputs y dependencias, llama a la función pública, y luego verifica el resultado o el efecto visible externo.

Supongamos que un módulo de facturas exporta esta función:

export function calculateInvoiceTotal(
  subtotal: number,
  taxRate: number,
  discountRate: number,
): number {
  const discounted = subtotal * (1 - discountRate)
  return Math.round(discounted * (1 + taxRate) * 100) / 100
}

El test debería centrarse en el comportamiento financiero, no en la variable local denominada discounted:

import { calculateInvoiceTotal } from './calculateInvoiceTotal'

describe('calculateInvoiceTotal', () => {
  it('applies percentage discount before tax', () => {
    const subtotal = 100
    const taxRate = 0.2
    const discountRate = 0.1

    const total = calculateInvoiceTotal(subtotal, taxRate, discountRate)

    expect(total).toBe(108)
  })

  it('rounds the final amount to currency precision', () => {
    const total = calculateInvoiceTotal(19.99, 0.2, 0)

    expect(total).toBe(23.99)
  })
})

Each it designa un comportamiento. Si una refactorización posterior cambia la cálculo internamente pero preserva el contrato, estos tests deberían seguir siendo útiles.

Pruebas asíncronas necesitan la misma disciplina. resolves y rejects haga explícita la conclusión esperada de la promesa:

it('returns an invoice from the API', async () => {
  await expect(fetchInvoice('invoice-123')).resolves.toMatchObject({
    id: 'invoice-123',
  })
})

it('rejects when the invoice is missing', async () => {
  await expect(fetchInvoice('missing')).rejects.toThrow('Invoice not found')
})

El error peligroso es crear una expectativa rechazada sin esperar o devolverla. La guía enfocada en Jest identifica los olvidados await o return La pregunta es: ¿qué sucede si olvidamos esperar a que se resuelva la promesa?Prácticas de pruebas unitarias con JestUna prueba que nunca espera a su aserción no ha verificado el camino de falla.

Evita tres hábitos que producen confianza frágil:

• Pruebas de ayudantes privados: Prueba el comportamiento exportado a menos que el ayudante represente una frontera pública significativa.
• Verificar el estado interno: Preferir valores devueltos, eventos emitidos, registros persistidos o salida visible.
• Sobrealimentar afirmaciones de llamada: toHaveBeenCalled() solo dice poco. Verifica los argumentos relevantes y el comportamiento resultante.

Una lista de verificación de PR puede permanecer corta:

• ¿Cubre cada prueba un comportamiento?
• ¿La prueba sigue el patrón Arrange, Act, Assert?
• ¿Se esperan las expectativas asíncronas?
• ¿Se mockean las dependencias solo en una frontera clara?
• ¿La prueba sobreviviría a una refactorización interna?

Para ejemplos específicos de componentes, Capgo’s Guía de Pruebas Unitarias de React aplica los mismos principios de comportamiento a la salida renderizada y las interacciones de usuario.

Estrategias de Mockeo que Funcionan

El mockeo se vuelve difícil cuando un conjunto crece porque cada atajo crea una obligación de mantenimiento. Una función manual jest.fn() puede ser exactamente correcta para una llamada de retorno. Un reemplazo de módulo puede aislar un SDK. Un interceptador de red puede preservar más del comportamiento de solicitud real de la aplicación. La elección debe seguir la hebra que estás probando.

Considera un validador de pago que llama a un SDK de Stripe, registra un evento de auditoría y alcanza un servicio de riesgo HTTP. Una prueba unitaria enfocada podría espiar en el logger, reemplazar el pago SDK, y interceptar la solicitud de riesgo. Cada técnica controla una frontera diferente.

Espías manuales para decisiones locales

Usar un espía cuando la dependencia ya está inyectada y el test necesita observar o controlar una interacción:

const audit = {
  record: jest.fn(),
}

const result = await validatePayment(input, {
  paymentClient,
  audit,
})

expect(audit.record).toHaveBeenCalledWith(
  expect.objectContaining({ event: 'payment.validated' }),
)
expect(result.status).toBe('approved')

Restablecer el estado entre casos. El estado compartido es una fuente común de fallas Jest, y se recomienda combinarlo beforeEach con mockeo para evitar el conteo de llamadas y la fuga de estado ("Maestría en pruebas unitarias de Jest).

Mocks de módulo para SDKs pesados

Un módulo de Stripe o nativo a menudo realiza la configuración tan pronto como carga. Reemplazar ese módulo cuando cargar la implementación de producción introduciría credenciales, ligaduras nativas o comportamiento irrelevante:

jest.mock('stripe', () => ({
  payments: {
    authorize: jest.fn(),
  },
}))

La prueba debe seguir afirmando el valor devuelto por la aplicación. Un llamado de aserción SDK exitoso sin un resultado significativo puede demostrar solo que el mock estaba configurado.

MSW para grietas HTTP

Para code que posee la construcción de solicitudes, la interpretación de respuestas, las reintentos o la traducción de errores, MSW puede interceptar el capa HTTP mientras preserva el camino de solicitud:

server.use(
  http.post('/risk/check', async () => {
    return HttpResponse.json({ decision: 'review' })
  }),
)

Esto suele dar una confianza mejor que mockear una capa baja fetch llamar en cada prueba. También hace que los escenarios de respuesta sean más fáciles de nombrar y reutilizar en entornos de Node y similares a navegadores.

Simular en la unión, no en la unión misma.

El exceso de simulación crea pruebas que pasan mientras que la integración de cableado está rota. La simulación insuficiente hace que las redes reales, sistemas de archivos, relojes o bases de datos entren en las pruebas unitarias y producen suites lentas e impredecibles. Mantenga la lógica pura libre de todo I/O, luego mueva la verificación de límites a las pruebas de contrato o integración donde importa la interfaz.

Integrar Jest con CI y Gates de Cobertura

El CI debe responder a dos preguntas diferentes. Primero, ¿rechaza la suite de unidades rápida un cambio peligroso? Segundo, ¿confirman las pruebas de integración más lentas que los límites importantes todavía funcionan? Colocar cada prueba en un comando indiferenciado hace que la retroalimentación sea más difícil de interpretar y anima a los desarrolladores a saltarse la suite.

A GitHub Actions workflow can pin the Node runtime, use the lockfile for dependency caching, and run unit checks with Jest’s CI mode:

name: test

on:
  pull_request:
  push:

jobs:
  unit:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
          cache-dependency-path: package-lock.json

      - run: npm ci
      - run: npm run test:unit, --ci --coverage

      - uses: actions/upload-artifact@v4
        with:
          name: coverage-${{ matrix.node }}
          path: coverage/

El script de paquete puede separar pruebas rápidas de trabajo de integración:

{
  "scripts": {
    "test:unit": "jest --runInBand tests/unit",
    "test:integration": "jest --runInBand tests/integration"
  }
}

Utilice un umbral de cobertura que refleje el riesgo en lugar de seleccionar un número universal por hábito:

module.exports = {
  collectCoverageFrom: ['src/**/*.{js,ts,tsx}'],
  coverageThreshold: {
    global: {
      branches: 70,
      functions: 80,
      lines: 80,
      statements: 80
    }
  }
}

Esos valores son ejemplos de configuración, no estándares de la industria verificados. Establezca el piso real desde el umbral actual del repositorio, luego aumente cuando el equipo agregue cobertura significativa. Una puerta de enlace estricta puede bloquear una reparación urgente si mide generados o de bajo riesgo code. Una puerta de enlace indulgente puede dejar que los caminos críticos se descompongan sin ser notados.

Para repositorios grandes, utilice la fragmentación basada en matriz solo después de que la aislación de pruebas sea segura. Cada fragmento necesita una propiedad clara de su informe, y el estado final debe hacer visibles las fallas en la solicitud de extracción en lugar de enterrarlas en los registros. Los equipos también pueden subir la cobertura HTML como un artefacto y publicar lcov datos a Codecov o Coveralls, siempre y cuando el servicio esté configurado para fusionar los informes correctamente.

Leer disciplina operativa de CI junto a su diseño de flujo de trabajo, especialmente si varias aplicaciones comparten un repositorio. Capgo’s Guía de pruebas de integración de CI/CD Mantener confiables las pruebas unitarias de Jest a gran escala

Keeping Jest Unit Tests Trustworthy at Scale

A large Jest suite can pass consistently while testing the wrong things. Trust declines when tests depend on implementation details, snapshots grow beyond useful review, or shared mocks alter behavior far from the test that configured them.

Snapshots need deliberate ownership. They work well when rendered structure is a real contract, such as a stable component or serialized message. They create noise when developers approve broad updates without inspecting the output. Regenerate them intentionally, review the diff, and remove files that no longer protect meaningful behavior.

Leer más sobre la disciplina operativa de CI

Give each testing layer a narrow job:

• Pruebas unitarias puras: Verifique cálculos determinísticos, parseadores, reducidos, decisiones de políticas y mapeo de errores sin acceso a red ni sistema de archivos.
• Pruebas de contrato: Comprobar límites de módulos, formas de adaptadores, cargas de solicitud y comportamiento de plugins.
• Pruebas de cobertura E2E delgadas: Realizar un pequeño conjunto de viajes de usuario reales a través de la web, Capacitor, o una caja de Electron.

Esta disposición mantiene las pruebas unitarias rápidas mientras se comprueban los límites donde los mocks pueden detenerse representando la producción. También evita un modo de falla móvil común: probar una actualización nativa completa o un flujo de permisos a través de un camino de interfaz de usuario costoso en lugar de aislar la lógica de decisiones de JavaScript.

Mantén un comportamiento por it() Entonces, solo asuma el orden de llamada cuando el orden pertenece al contrato. Un falso fiable, como un repositorio en memoria con métodos que exponen registros almacenados, suele dar mejores retroalimentaciones que valores de retorno fijos que simplemente copian la implementación actual.

Una prueba que pasa debería explicar qué usuarios o módulos vecinos pueden confiar, no cómo hoy en día code está organizado.

Programar revisiones periódicas de la salud de las pruebas. Revisar pruebas que fallan, capturas de pantalla obsoletas, configuración redundante y mocks que ya no coinciden con el comportamiento de producción. Borrar una prueba de baja valor puede ser más seguro que agregar otra afirmación a una prueba que ya oculta demasiado.

Track flakiness in CI dashboards. If a test fails without a code change, preserve the failure evidence, isolate shared state, control time and randomness, and reduce worker pressure when the runner is overloaded. Set worker limits from measurements on your CI machines, because extra parallelism can increase contention and make the suite slower. Keep the worker setting documented with the runner configuration so future changes remain intentional.

Marco de decisión y pasos siguientes para su equipo

Jest remains a sound default when a repository already has a stable suite, established transforms and mocks, and a team that values migration safety over runner experimentation. Compare alternatives when a new project is ESM-first, native feedback is a priority, or watch-mode reruns regularly interrupt development. Benchmark results can vary substantially by repository architecture and transformer work, so treat published comparisons as directional rather than promises.

Utilice cuatro criterios:

1. Herramientas existentes: Mantén Jest cuando la configuración, las utilidades de prueba y las convenciones de CI ya funcionan.
2. Formato de módulo: Reconsidere el ejecutor cuando las dependencias ESM solo requieren repetidamente excepciones o soluciones personalizadas.
3. Expectativas de retroalimentación: Medir cambios de observación representativos en el repositorio real, no en un proyecto de demostración vacío.
4. Capacidad del equipo: Un ejecutor familiar que el equipo puede configurar y depurar puede producir mejores resultados que una herramienta más rápida utilizada mal.

Vitest, el ejecutor de pruebas integrado de Node, y Playwright abordan necesidades diferentes. Playwright pertenece principalmente a la cobertura de pruebas E2E en el navegador. El ejecutor de Node puede ser adecuado para servicios de Node enfocados. Vitest a menudo se ajusta a proyectos de ESM y Vite orientados. Jest sigue siendo adecuado para equipos que dependen de mocks maduros, transformaciones y convenciones de CI existentes. Elija el ejecutor que preserve límites confiables mientras mantiene la retroalimentación útil.

Un reinicio práctico de 90 días

Mes uno, audita la suite. Asigna un propietario para catalogar pruebas que se desmayan, capturas muertas, afirmaciones acopladas a la implementación y pruebas que realizan I/O real. El resultado debe ser una lista escrita de eliminaciones, reparaciones y límites que necesitan cubrimiento de integración.

Mes dos, estandariza el diseño. Agrega utilidades de prueba compartidas, documenta convenciones de mocking y presenta informes de cobertura para paquetes importantes. Registra qué paquetes tienen puertas y qué comportamientos aún carecen de pruebas enfocadas, para que la base permanezca revisable.

Mes tres, estabiliza la entrega. Ajusta los trabajadores de CI, separa trabajos de unidades y de integración, establece un piso de cobertura basado en riesgo, y documenta convenciones en un } TESTING.md. El pipeline debe informar fracasos accionables, mientras que nuevas pruebas siguen los mismos límites y reglas de mocking.

Revisar la suite en un horario recurrente. Elimine capturas de pantalla obsoletas, configuración redundante y mocks que ya no coinciden con el comportamiento de producción. Una prueba de bajo valor puede ser más seguro eliminarla que reforzarla con otra afirmación. Registre fallas flacas en CI, preservar evidencia, aislar estado compartido, controlar el tiempo y la aleatoriedad, y reducir la presión de los trabajadores cuando se produzca la contienda. Establezca límites de trabajadores a partir de mediciones en las máquinas de CI y manténgalos documentados con la configuración del ejecutor.

Estas prácticas pertenecen junto a otras prácticas de desarrollo de software. For a tested JavaScript fix targeting Capacitor or Electron users, Capgo can deliver signed JavaScript, CSS, configuration, and asset bundles through targeted channels, with rollback protection and release observability, without requiring a store review for every web-layer correction.

Si su equipo envía aplicaciones Capacitor o Electron, visite Capgo to assess how live JavaScript updates fit controlled channels, staged rollouts, and rollback protection. Start by documenting Jest boundaries and CI gates, then define where Capgo belongs in the recovery path for fixes that need prompt delivery.