Prueba de unidades de 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 así enviar una factura de cobro rota, una bandera de característica caducada o una rama específica de plataforma. La falla suele comenzar antes: una prueba de unidad refleja todavía el comportamiento antiguo, un mock oculta una dependencia cambiada o la CI ejecuta un entorno diferente al 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 Pruebas unitarias de Jest se trata mejor como una decisión de flujo de trabajo en constante evolución, no solo como un comando de ejecución. Las preguntas útiles son prácticas: ¿cómo rápidamente un desarrollador puede confiar en una falla, qué límites deben permanecer aislados, qué cobertura pertenece en CI y si Jest todavía se ajusta al sistema de módulos del proyecto y las expectativas de retroalimentación? Esta guía se centra en esas decisiones a través de servicios de Node, aplicaciones web, proyectos Capacitor y aplicaciones Electron. Para un contexto más amplio sobre dónde se ajustan las comprobaciones automatizadas en la entrega, consulte pruebas automatizadas en flujos de trabajo de software modernos.

Contenido de la Tabla

• context: Página/área: sitio web de marketing de Capgo. Rol: etiqueta de UI corta o elemento de navegación. Visto en: página blog/[slug].astro. Clave de mensaje `table_of_contents` (Contenido de la Tabla).
• ¿Por qué las pruebas unitarias de Jest siguen siendo importantes en 2026?
  • Instalación y configuración de Jest en diferentes entornos
  • Add only the browser shims your code needs
• Agrega solo los shim de navegador que necesite tu __CAPGO_KEEP_0__
• Escritura de tus primeras pruebas unitarias fiables
  • Estrategias de simulación que realmente escalan a gran escala. Simulación manual para decisiones locales
  • Mockeos de módulos para SDKs pesados
  • MSW para grietas HTTP
• Integrando Jest con CI y puertas de cobertura
• Mantener pruebas unitarias de Jest confiables a gran escala
  • 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

¿Por qué las pruebas unitarias de Jest siguen siendo importantes en 2026?

Jest sigue siendo relevante porque resuelve más que la sintaxis de afirmaciones. Proporciona a los equipos un lugar repetible para verificar la lógica de negocio, controlar las fronteras de dependencia, hacer cumplir las expectativas de cobertura y ejecutar comprobaciones antes de que un paquete móvil o de escritorio alcance a los usuarios. Ese flujo de trabajo importa cuando el mismo comportamiento de JavaScript se ejecuta en una caja de shell de navegador, una Capacitor WebView, un renderizador de Electron y un proceso de Node con diferentes APIs de plataforma alrededor de él.

La adopción de Jest también tiene peso histórico. Facebook lo creó en 2011 para una reescritura de chat de JavaScript, lo abrió en 2014y 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.

Saltarse las pruebas unitarias a favor de la cobertura de fin a comienzo parece más barato hasta que cada pequeño error requiere un lanzamiento de aplicación completo, configuración de dispositivo, ruta de red y diagnóstico específico de plataforma. Las pruebas E2E son valiosas para los viajes críticos de lanzamiento. Son un mal sustituto de las comprobaciones rápidas y enfocadas alrededor de las calculaciones de impuestos, los manifestos de actualización, las decisiones de permiso, los adaptadores de almacenamiento y la mapeación de errores.

Regla práctica: Mantén a Jest cuando su ecosistema reduce el riesgo de migración y tu conjunto de pruebas proporciona a los desarrolladores retroalimentación 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 a 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 volatilidad a gran escala y tomarás una decisión deliberada de mantener o cambiar.

Instalando y configurando a Jest en diferentes entornos

Comience con la configuración más pequeña que coincida con el tiempo de ejecución. Un servicio de Node suele necesitar el entorno predeterminado de Jest y un script de prueba. Un módulo de Capacitor o Electron que se enfrenta a un navegador necesita globales similares a DOM, mientras que TypeScript agrega una decisión de transformación que puede afectar la depuración, la compatibilidad de módulos y el comportamiento de arranque.

Para un proyecto de Node plano, 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. Revisar el entorno de prueba, las transformaciones, las alias de módulo y los archivos de configuración antes de comprometerlo.

Elige la transformación 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 TypeScript configuration utilizando ts-jest Aparece de la siguiente manera:

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 basados en Babel o mixtos, mantenga el archivo Babel explícito:

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

Sólo agregue los shims de navegador que necesita su code

Capacitor y pruebas de Electron importan frecuentemente code que espera window.matchMedia o IntersectionObserver¿O

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

¿O 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 (¿O¿O experimentalVMModules ¿O

Para una guía de instalación paso a paso enfocada en JavaScript, utilice 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 que pasa 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 plugins donde sea necesario.

Escrita de tus primeras pruebas unitarias confiables

Una prueba unitaria útil describe un comportamiento observable en un contexto controlado. El patrón Arrange, Act, Assert mantiene esa intención visible: prepare los inputs y dependencias, llama a la función pública, luego verifica el resultado o el efecto externamente visible.

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
}

La prueba debe 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)
  })
})

Cada it Cada uno de ellos describe una conducta. Si un refactor posterior cambia la calculación internamente pero preserva el contrato, estas pruebas deben seguir siendo útiles.

Los tests asíncronos necesitan la misma disciplina. Jest’s resolves y rejects hacer explícita la consecuencia 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 de Jest enfatiza lo que se ha olvidado await o return Las declaraciones como causa de falsos positivos y tests que pasan sin una advertencia clara (Prácticas de pruebas unitarias de Jest)

Una prueba que nunca espera su afirmación no ha verificado el camino de falla.

• Evite tres hábitos que producen confianza frágil: Probar ayudantes privados:
• Verificando el estado interno: Preferir valores devueltos, eventos emitidos, registros persistidos o salida visible.
• Sobrecargar las afirmaciones de llamada: toHaveBeenCalled() solo dice poco. Verifique 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 de 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 para la salida renderizada y las interacciones de usuario.

Estrategias de Mockeo que Funcionan a Gran Escala

El mockeo se vuelve difícil cuando un conjunto crece porque cada atajo crea una obligación de mantenimiento. Una implementación manual jest.fn() puede ser exactamente correcta para una llamada de retorno. Una 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 Stripe SDK, registra un evento de auditoría y alcanza un servicio de riesgo HTTP. Un test unitario enfocado podría espiar en el logger, reemplazar el pago SDK, y interceptar la solicitud de riesgo. Cada técnica controla una frontera diferente.

Manual espías para decisiones locales

Utilice 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 inestables, y se recomienda combinarlo beforeEach con la limpieza de mocks para prevenir los conteos de llamadas y la fuga de estado (Maestría en pruebas unitarias de Jest).

Mocks de módulos para SDKs pesados

Un módulo de Stripe o nativo a menudo realiza la configuración tan pronto como carga. Reemplace 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(),
  },
}))

El test debería seguir afirmando el valor devuelto por la aplicación. Un llamado de aserción de SDK exitoso sin un resultado significativo puede demostrar solo que el mock se configuró.

MSW para grietas HTTP

Para code que posee la construcción de solicitudes, la traducción de respuestas, las reintentadas 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' })
  }),
)

Normalmente esto da una confianza mejor que mockear una llamada baja en cada test. También hace que los escenarios de respuesta sean más fáciles de nombrar y reutilizar en ambientes de Node y navegador similares. fetch Esta suele dar una confianza mejor que mockear una llamada baja en cada test. También hace que los escenarios de respuesta sean más fáciles de nombrar y reutilizar en ambientes de Node y navegador similares.

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

El exceso de mockeo crea pruebas que pasan mientras que la integración de cableado está rota. El sub-mockeo trae redes, sistemas de archivos, relojes o bases de datos reales a las pruebas unitarias y produce suites lentas e impredecibles. Mantén la lógica pura libre de todo I/O, luego mueve la verificación de límites a las pruebas de contrato o integración donde importa la interfaz.

Integrar Jest con CI y Puertas de Cobertura

La 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 todas las pruebas 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.

Un flujo de trabajo de GitHub Actions puede pinchar el tiempo de ejecución de Node, utilizar el archivo de bloqueo para la caché de dependencias y ejecutar las pruebas unitarias con el modo de CI de Jest:

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 del paquete puede separar las pruebas rápidas de la integración:

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

Utiliza 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. Establece el piso real desde la base actual del repositorio, luego aumenta cuando el equipo agrega cobertura significativa. Una puerta estricta puede bloquear una corrección urgente si mide generados o de bajo riesgo code. Una puerta leniente puede dejar que los caminos críticos se descompongan sin ser notados.

Para grandes repositorios, 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 con el diseño de su flujo de trabajo, especialmente si varias aplicaciones comparten un repositorio. La guía de integración CI/CD de Capgo es útil cuando el estado de las pruebas debe conectarse con la automatización de compilación y lanzamiento móvil. Mantener confiables las pruebas unitarias de Jest a gran escala Un gran conjunto de pruebas de Jest puede pasar consistentemente mientras se prueban las cosas incorrectas. La confianza declina cuando las pruebas dependen de detalles de implementación, las capturas crecen más allá de la revisión útil o los mocks compartidos alteran el comportamiento lejos de la prueba que los configuró.

Las capturas necesitan una propiedad deliberada. Funcionan bien cuando la estructura renderizada es un contrato real, como un componente estable o un mensaje serializado. Creen ruido cuando los desarrolladores aprueban actualizaciones amplias sin inspeccionar el resultado. Regenerénelas intencionalmente, revise la diferencia y elimine los archivos que ya no protegen el comportamiento significativo.

Utilice capas en lugar de forzar a Jest a que controle todo

Dé a cada capa de pruebas una tarea estrecha:

]} ]}

Give each testing layer a narrow job:

• Pruebas unitarias puras: Verificar cálculos deterministas, parsers, reducidos, decisiones de política y mapeo de errores sin acceso a la red o al sistema de archivos.
• Pruebas de contrato: Comprobar límites de módulos, formas de adaptadores, cargas de peticiones y comportamiento de plugins.
• Cobertura E2E delgada: 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 un 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.

Mantener un comportamiento por it() entonces las fallas permanecen diagnoscables. Sólo aser la secuencia de llamadas cuando la secuencia pertenece al contrato. Un falso consultable, 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. Eliminar una prueba de baja valor puede ser más seguro que agregar otra aserción a una prueba que ya oculta demasiado.

Monitorez la inestabilidad en las tableros de CI. Si una prueba falla sin un cambio code, preserven la evidencia de la falla, aíslen el estado compartido, controlen el tiempo y la aleatoriedad, y reduzcan la presión de los trabajadores cuando el ejecutor está sobrecargado. Establezcan límites de trabajadores a partir de mediciones en sus máquinas de CI, porque la paralelización adicional puede aumentar la contienda y hacer que el conjunto de pruebas sea más lento. Mantengan la configuración del trabajador documentada con la configuración del ejecutor para que los cambios futuros sean intencionales.

Marco de decisión y pasos siguientes para su equipo

Jest sigue siendo una opción sonora por defecto cuando un repositorio ya tiene un conjunto de pruebas estable, transformaciones y mocks establecidas, y un equipo que valora la seguridad de la migración sobre la experimentación del ejecutor. Compare alternativas cuando un nuevo proyecto es ESM-first, la retroalimentación nativa es una prioridad, o los reanudaciones de modo de observación regularmente interrumpen el desarrollo. Los resultados de las pruebas pueden variar sustancialmente según la arquitectura del repositorio y el trabajo del transformador, por lo que traten las comparaciones publicadas como direcciones más que promesas.

Utilice cuatro criterios:

1. Herramientas existentes: Mantenga 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 de 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 quebradizas, instantáneas 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 cobertura de integración.

Mes dos, estandariza el diseño. Agrega utilidades de prueba compartidas, documenta convenciones de mocking y introduce 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 e integración, establece un piso de cobertura basado en riesgos y documenta convenciones en un documento vivo. TESTING.mdLa pipeline debe informar fallas acciones, mientras que nuevas pruebas siguen los mismos límites y reglas de mocking.

Revisa la suite en un horario recurrente. Elimina capturas de pantalla obsoletas, configuraciones redundantes y mocks que ya no coinciden con el comportamiento de producción. Un test de bajo valor puede ser más seguro eliminarlo que reforzarlo con otra afirmación. Registra fallas flacas en CI, preserva evidencia, aísla el estado compartido, controla el tiempo y la aleatoriedad, y reduce la presión de los trabajadores cuando aparece la contienda. Establece límites de trabajadores a partir de mediciones en las máquinas de CI y manténlos documentados con la configuración del ejecutor.

Estas prácticas pertenecen junto a mejores prácticas de desarrollo de software. Para un arreglo de JavaScript probado que se dirija a usuarios de __CAPGO_KEEP_0__ o Electron, __CAPGO_KEEP_1__ puede entregar paquetes de JavaScript, CSS, configuración y activos firmados a través de canales dirigidos, con protección de rollback y observabilidad de la liberación, sin requerir una revisión de tienda para cada corrección de capa web.. 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.

para evaluar cómo las actualizaciones de JavaScript en vivo se ajustan a los canales controlados, los despliegues estadiados y la protección de rollback. Comienza documentando los límites de Jest y las puertas de CI, luego define dónde Capacitor pertenece en el camino de recuperación para arreglos que necesitan una entrega rápida. 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.