Formación corporativa en Jest

La API expect es la pieza central de Jest: todas las verificaciones del comportamiento del código pasan por ella. Este módulo recorre los matchers que cubren el 90% de los casos en proyectos reales: igualdad estricta (toBe), igualdad estructural (toEqual, toStrictEqual), comparaciones numéricas (toBeGreaterThan, toBeCloseTo), matchers de cadenas (toMatch, toContain), de colecciones (toContain, toHaveLength, toEqual con arrays), de objetos (toMatchObject, toHaveProperty) y de excepciones (toThrow, toThrowErrorMatchingSnapshot).

Se explican también los matchers asimétricos (expect.any(Function), expect.objectContaining(...), expect.stringMatching(...)) que permiten escribir aserciones flexibles sobre estructuras parciales y la creación de matchers personalizados con expect.extend({...}) para encapsular reglas de negocio del dominio (por ejemplo, toBeValidEmail). Al finalizar el módulo serás capaz de elegir el matcher adecuado para cada caso, evitar falsos positivos por igualdad por referencia y construir tests legibles que documentan el contrato de cada función.

Los hooks del ciclo de vida son la herramienta principal para preparar el escenario de cada test, compartir fixtures entre pruebas y limpiar recursos al terminar. Este módulo cubre los cuatro hooks que ofrece Jest: beforeEach (se ejecuta antes de cada test del bloque), afterEach (después de cada test), beforeAll (una vez al inicio del bloque) y afterAll (una vez al final). Se explica la diferencia entre instanciar fixtures en cada test y compartirlos a nivel de suite, y cómo evitar el acoplamiento entre tests por estado mutable.

La organización con describe permite agrupar tests por contexto y anidar suites con sus propios hooks. Jest aplica los hooks de fuera hacia dentro: primero el beforeEach de la suite externa, después el de la interna, y al revés con afterEach. Conocer este orden es clave para diseñar fixtures jerárquicos en tests de servicios, controladores y repositorios. Al finalizar el módulo organizarás suites legibles con describe, evitarás tests inestables por estado compartido y aplicarás los hooks correctos para escenarios con bases de datos, servidores HTTP o mocks que deben restablecerse.

Los dobles de prueba son fundamentales para aislar la unidad bajo test de sus dependencias externas (APIs, bases de datos, sistema de archivos, reloj del sistema). Este módulo recorre las cuatro herramientas que ofrece Jest: jest.fn() para crear funciones mock independientes con seguimiento de llamadas y valores de retorno configurables, jest.spyOn(objeto, 'metodo') para envolver un método existente preservando o sobrescribiendo su comportamiento, jest.mock('modulo') para reemplazar un módulo completo de forma automática y los manual mocks en __mocks__/ para definir implementaciones reutilizables.

El módulo cubre también los fake timers modernos de Jest 30 (jest.useFakeTimers({ advanceTimers: true })), que permiten avanzar el tiempo virtualmente con jest.advanceTimersByTime(ms) y verificar setTimeout, setInterval, Date.now() y requestAnimationFrame sin esperas reales. Al finalizar el módulo escribirás tests rápidos y deterministas que aislan la lógica del código de sus dependencias, restablecen mocks entre tests con jest.restoreAllMocks() y verifican interacciones con toHaveBeenCalledWith, toHaveBeenCalledTimes y mock.calls.

JavaScript moderno es asíncrono por naturaleza: fetch, fs/promises, consultas a bases de datos, lecturas de cola y orquestación de microservicios devuelven promesas. Este módulo enseña cómo escribir tests fiables sobre código asíncrono evitando los dos problemas más habituales: tests que pasan sin haber llegado a verificar nada (porque el test acaba antes de que la promesa se resuelva) y tests inestables por race conditions con timeouts arbitrarios.

Se cubren las cuatro estrategias soportadas por Jest: async/await en el callback del test (recomendado en proyectos modernos), retornar la promesa para que Jest espere su resolución, callbacks con done para APIs antiguas y los matchers .resolves y .rejects para verificar el valor resuelto o el error rechazado de forma declarativa. También se explica el uso de expect.assertions(n) para garantizar que un test asíncrono ejecuta el número esperado de aserciones, especialmente útil cuando se prueba el camino de error con try/catch. Al finalizar el módulo escribirás tests de servicios HTTP, repositorios de base de datos y handlers de eventos asíncronos sin falsos positivos ni inestabilidad.

El snapshot testing es una técnica que te permite verificar estructuras de datos complejas (árboles de componentes React, respuestas JSON, mensajes de error formateados) sin escribir aserciones manuales por cada propiedad. Jest serializa el valor en la primera ejecución, lo guarda en un archivo .snap junto al test y, en ejecuciones posteriores, compara el valor actual con el almacenado. Si difieren, el test falla y muestra un diff legible que revisas antes de actualizar el snapshot con --updateSnapshot (-u).

En este módulo aprendes cuándo el snapshot es la mejor opción y cuándo conviene evitarlo: ideal para outputs amplios y estables, peligroso para valores sensibles a fechas, IDs aleatorios o entornos. Se cubren los snapshots externos (toMatchSnapshot()) que viven en la carpeta __snapshots__/, los inline snapshots (toMatchInlineSnapshot()) que Jest inyecta en el propio archivo de test para revisar cambios en el mismo punto donde se ejecutan, y las buenas prácticas para revisar diffs en pull requests sin aprobar regresiones por inercia. Al finalizar el módulo usarás snapshots de forma disciplinada para tests de componentes UI y outputs estructurados.

La cobertura de código mide qué porcentaje de las líneas, ramas, funciones y sentencias del código fuente se ejecutan durante los tests. Jest incorpora Istanbul (y opcionalmente el motor V8 de Node.js) sin configuración adicional: basta con ejecutar jest --coverage para obtener un reporte por consola y carpetas coverage/lcov-report/ en HTML. Este módulo enseña a interpretar esos reportes (qué significa una rama no cubierta, dónde priorizar nuevos tests) y a configurar collectCoverageFrom para incluir solo el código relevante y excluir archivos generados, configuración o tipos.

La parte avanzada cubre coverageThreshold, la opción que permite definir umbrales mínimos por proyecto, archivo o glob de archivos. Si la cobertura cae por debajo del umbral, Jest devuelve código de salida 1 y bloquea el pipeline de CI/CD. Es la herramienta clave para imponer disciplina en pull requests y garantizar que el equipo no añade código sin tests. Al finalizar el módulo integrarás Jest con GitHub Actions, GitLab CI o Jenkins, publicarás reportes de cobertura como artefactos del pipeline y configurarás umbrales realistas que crecen progresivamente con la madurez del proyecto.

Este módulo aborda los tres ecosistemas donde Jest sigue siendo el estándar en 2026 y la decisión más frecuente entre equipos: ¿Jest o Vitest?. Se cubre la integración con React Testing Library para tests de componentes React 19 (queries getByRole, findByText, eventos con userEvent y matchers DOM como toBeInTheDocument), la configuración de TypeScript 5 con ts-jest o el preset de SWC para compilar tests sin perder type-checking, y el uso del NestJS Testing Module (Test.createTestingModule) para escribir tests unitarios de servicios y controladores con inyección de dependencias mockeadas.

La sección final compara Jest contra Vitest desde una óptica práctica: rendimiento (Vitest es más rápido en proyectos Vite), ecosistema (Jest tiene más plugins y mejor integración con CRA, Next.js y NestJS), API (casi idéntica, lo que facilita migraciones progresivas) y criterios para decidir si conviene migrar un proyecto existente. Al finalizar el módulo escribirás tests de componentes React 19 con Jest y RTL, configurará un proyecto TypeScript 5 con tipos correctos en sus mocks y tomará decisiones informadas sobre cuándo permanecer en Jest y cuándo migrar a Vitest.