Guía completa de pruebas unitarias en frontend con Jest

Cuando empiezas a tomarte en serio el frontend, tarde o temprano llegas al mismo punto: necesitas pruebas unitarias que te den confianza para tocar el código sin miedo. Ahí es donde Jest, junto con herramientas como React Testing Library o jest-preset-angular, se convierten en tus mejores aliados.

En esta guía vamos a ver, con calma pero al grano, cómo plantear y montar una estrategia de tests unitarios en frontend usando Jest: qué tipo de pruebas tiene sentido hacer, cómo configurarlo en proyectos React, Angular o TypeScript, cómo escribir buenas pruebas (sin caer en detalles de implementación) y qué herramientas tienes para comparar resultados, trabajar con el DOM, mocks, async, cobertura y mucho más.

¿Por qué las pruebas unitarias importan tanto en frontend?

Los desarrolladores con experiencia asumen algo muy simple: su código va a tener errores. No se trata de ser más o menos listo, sino de aceptar que sin una buena batería de tests, cualquier cambio puede romper funcionalidades clave… y que el usuario se entere antes que tú.

Las pruebas unitarias consisten en probar pequeñas piezas de código de forma aislada: funciones, métodos, componentes o servicios. La idea es clara: dado un input concreto, esperas un output concreto. Si eso se cumple hoy y en el futuro, el comportamiento se mantiene estable aunque el código interno cambie.

Entre los beneficios más importantes de tener buenos tests unitarios están cosas bastante tangibles: detectar bugs pronto, documentar el comportamiento del sistema y facilitar refactors grandes sin convertir tu vida en una ruleta rusa de deploys.

Trofeo de test y tipos de pruebas en frontend

En los últimos años se ha popularizado el llamado “Trofeo de Test”, una alternativa moderna a la clásica pirámide de testing. Más que obsesionarse con un porcentaje de cobertura, este modelo intenta equilibrar esfuerzo, coste y nivel de confianza a lo largo de distintos tipos de pruebas.

En el Trofeo de Test se suelen considerar cuatro niveles: pruebas estáticas, unitarias, de integración y end-to-end. Cada una aporta un tipo de feedback diferente y conviene combinarlas en lugar de apostar solo por un tipo.

Pruebas estáticas: linters y análisis de código

Las pruebas estáticas son las que se aplican sin ejecutar el código. Se parecen a revisar un libro buscando faltas de ortografía antes siquiera de leer la historia. Aquí entran herramientas como ESLint para JavaScript o reglas específicas para TypeScript.

• Comprueban que el código sigue unas reglas y estándares (naming, formato, patrones prohibidos, etc.).
• Detectan errores comunes antes de que lleguen al runtime, como usos sospechosos de variables, imports muertos o tipos mal inferidos.
• Favorecen un estilo homogéneo que facilita el trabajo en equipo y el mantenimiento.

En proyectos TypeScript modernos lo típico es combinar ESLint y el propio compilador de TS para atrapar tanto errores de estilo como problemas de tipos antes siquiera de lanzar una prueba con Jest.

Pruebas unitarias: la primera línea de defensa

Las pruebas unitarias son las que se hacen sobre la unidad mínima de lógica: una función pura, un método, un hook, un componente pequeño o un servicio sencillo. En backend solemos hablar de clases y métodos; en frontend, la unidad puede ser también un componente o un trozo de lógica encapsulada.

En el ecosistema JavaScript y TypeScript verás nombres como Jest, Mocha, Chai o Vitest, aunque Jest se ha convertido de facto en el estándar para frontend, sobre todo gracias a su integración con React Testing Library y presetes como jest-preset-angular.

Es importante recordar que las pruebas unitarias no se preocupan de la implementación interna, sino de la salida esperada: dado un input conocido, la función o componente debe producir un resultado determinado, independientemente de cómo esté escrito por dentro.

Pruebas de integración: que las piezas hablen entre sí

Las pruebas de integración se centran en cómo se combinan varios módulos o componentes. No te quedas solo con una función aislada, sino con la interacción entre servicios, componentes y lógica de negocio.

• Definen escenarios donde varias partes colaboran: un formulario que llama a un servicio, que a su vez transforma datos y los muestra en la interfaz.
• Ayudan a detectar errores en los límites entre módulos, que es donde muchas veces se cuelan bugs de datos, tipos o contratos de APIs.
• En frontend con TypeScript puedes apoyarte en Supertest, Cypress o incluso pruebas con Jest que ejercitan varios componentes y servicios a la vez.

En el mundo React, esta “integración” suele testearse con React Testing Library + Jest, renderizando componentes que ya usan otros internos y servicios mockeados. En Angular, lo habitual es montar el componente con TestBed y usar Jest como motor en lugar de Karma/Jasmine.

Pruebas end-to-end (E2E): el recorrido completo del usuario

Las pruebas E2E simulan el comportamiento real de un usuario navegando por la aplicación: abren páginas, hacen clics, rellenan formularios y esperan respuestas de la parte de servidor.

• Ejercitan la aplicación de extremo a extremo, desde la interfaz hasta la API (o un entorno simulado muy cercano a producción).
• Validan flujos críticos, como inicio de sesión, compras, formularios complejos o procesos de onboarding.
• Suelen implementarse con Cypress, Playwright, Puppeteer o Selenium en entornos web.

Estas pruebas son más lentas y fragiles, pero darán el nivel de confianza más alto para funcionalidades clave. El truco está en usarlas con cabeza, cubriendo solo los caminos realmente críticos y apoyándote en unitarias e integración para el resto.

¿Qué es exactamente un test unitario y qué lo hace bueno?

Más allá de las etiquetas, muchas personas se preguntan: qué cuenta como prueba unitaria en frontend. ¿Un componente aislado? ¿Una función? ¿Una página entera?

Una definición muy útil viene del TDD clásico: un test unitario representa un escenario, requisito funcional o criterio de aceptación pequeño. No tiene por qué limitarse a una sola función minúscula, pero sí debería ser rápido, estable y enfocado.

Características clave de un test unitario útil

• Se centra en una unidad acotada de comportamiento: una función, un método, un componente o un pequeño flujo.
• Es rápido y aislado: no depende de la red, ni de bases de datos reales, ni de timers largos. Si hay dependencias externas, se simulan.
• Proporciona un feedback claro: cuando falla sabes qué requisito ha dejado de cumplirse, no solo que “algo” se ha roto.
• Sirve como documentación viva: leyendo el test entiendes qué se espera que haga ese trozo de código.

En frontend moderno tiene mucho sentido que muchas de esas pruebas unitarias sean, en realidad, pruebas de integración pequeñas: un componente con sus hijos, un hook que usa un servicio, etc., siempre que sigan siendo rápidas y fiables.

Jest como framework de pruebas en frontend

Jest se ha ganado su hueco como framework de testing predominante en el ecosistema JavaScript. Grandes empresas como Facebook, Airbnb, Twitter o Spotify lo utilizan para testear sus aplicaciones React, Angular y otras tecnologías de frontend.

Una de sus grandes ventajas es que apenas requiere configuración para arrancar en proyectos JavaScript o TypeScript, y viene con herramientas integradas para mocks, spies, aserciones y cobertura de código, evitando depender de mil librerías adicionales.

Funciones básicas: describe, test/it, beforeEach y afterEach

La estructura típica de un fichero de pruebas con Jest se basa en unos cuantos bloques clave que verás una y otra vez:

• describe(nombre, fn): agrupa tests relacionados bajo una misma descripción. Ayuda a organizar y a leer los resultados en consola.
• test(nombre, fn) o it(nombre, fn): define una prueba concreta. Ambas funciones son equivalentes; elige la que más te guste.
• beforeEach(fn): se ejecuta antes de cada test del grupo. Ideal para configurar el estado inicial, mocks o instancias comunes.
• afterEach(fn): se ejecuta después de cada prueba. Útil para limpiezas, restaurar mocks o cerrar conexiones simuladas.

En cualquier test unitario, dentro de la función que pasas a test o it, vas a seguir siempre más o menos el mismo patrón: preparas los datos, ejecutas la función o renderizas el componente y usas expect(…) para afirmar el resultado esperado.

Matchers y comparaciones en Jest

El corazón de las aserciones en Jest es la función expect, que se encadena con distintos métodos para comprobar diferentes condiciones. Algunos de los más habituales son:

• .toBe(valor): comprueba igualdad estricta usando Object.is. Ideal para números, strings y booleanos.
• .toEqual(obj): realiza una comparación recursiva de objetos y arrays, perfecto para estructuras de datos complejas.
• .not: invierte el matcher, por ejemplo expect(false).not.toBe(true).
• .toBeDefined(): verifica que un valor no es undefined.
• .toContain o expect.arrayContaining: validan que un array o string incluye determinados elementos.

Sobre esta base, Jest añade otras muchas funciones específicas: .toHaveBeenCalled, .toHaveBeenCalledTimes, .toHaveBeenCalledWith para mocks, .toThrow para errores, o matchers extendidos cuando integras bibliotecas como @testing-library/jest-dom para trabajar con el DOM.

Testing del DOM con React Testing Library

Cuando se trata de componentes React, lo más habitual hoy en día es usar React Testing Library junto con Jest. La filosofía de esta librería es clara: testear los componentes como lo haría un usuario, dejando de lado los detalles internos de implementación.

En lugar de comprobar el estado interno del componente, se centra en consultar el DOM por el texto visible, el rol de accesibilidad o etiquetas asociadas, lo que, de rebote, fomenta buenas prácticas de accesibilidad.

Tipos de queries: getBy, queryBy y findBy

React Testing Library expone diferentes tipos de funciones para buscar elementos en el DOM renderizado, normalmente a través del objeto screen:

• getBy…: busca un elemento y lanza error si no lo encuentra. Es lo que quieres cuando el elemento debe existir para que el test pase.
• queryBy…: realiza la misma búsqueda pero devuelve null si no existe, sin romper el test. Útil para comprobar que algo no está presente.
• findBy…: igual que getBy, pero orientado a operaciones asíncronas. Devuelve una promesa y espera a que el elemento aparezca en el DOM tras una petición HTTP, un timeout, etc.

Estas variantes permiten cubrir tanto escenarios síncronos (elementos que deben estar ahí desde el principio) como asincrónicos (contenido que llega tras una llamada a la API o interacción del usuario).

Queries recomendadas para encontrar elementos

La documentación oficial de Testing Library propone un orden de preferencia para las queries, intentando siempre imitar cómo un usuario percibe la interfaz:

1. getByRole (con opción name): es la consulta más semántica, ya que localiza elementos por su rol accesible (button, heading, textbox, etc.). Debería ser tu primera opción casi siempre.
2. getByLabelText: perfecta para campos de formulario. Permite encontrar inputs y textareas por la etiqueta asociada, tal y como lo haría un lector de pantalla.
3. getByPlaceholderText: útil cuando solo hay un placeholder visible, aunque no sustituye a una etiqueta adecuada.
4. getByText: para contenido visible en elementos no interactivos: párrafos, divs, spans, etc.
5. getByDisplayValue: muy práctico para inputs ya rellenados, comprobando el valor que ve el usuario.

Además de estas, tienes las llamadas “semantic queries”:

1. getByAltText: localiza imágenes u otros elementos con atributo alt, imprescindible para accesibilidad.
2. getByTitle: se apoya en el atributo title, aunque este no siempre es leído por lectores de pantalla.

Por último, como último recurso está getByTestId, que busca elementos con un atributo data-testid. Es mejor reservarlo para casos donde no haya otra forma razonable de localizar el elemento (texto dinámico, elementos puramente decorativos, etc.).

Pruebas síncronas vs asíncronas en Jest

En JavaScript cada vez es más habitual trabajar con promesas, llamadas HTTP y temporizadores, y tus tests tienen que adaptarse a ello. Un test se considera asíncrono cuando espera a operaciones que no se resuelven en el mismo tick del event loop.

Un test es claramente sincrónico cuando:

• No usa funciones async ni await.
• No llama a APIs asíncronas ni a servicios que devuelvan promesas.
• No depende de setTimeout, setInterval o similares.

En cambio, es un test asíncrono cuando:

• La función de test está marcada con async y emplea await.
• Trabaja con funciones que devuelven promesas (fetch, axios, servicios HTTP, etc.).
• En React Testing Library, usa findBy o métodos de espera para aguardar a cambios en el DOM.

La clave es asegurarse de que Jest espera correctamente a que terminen esas operaciones. Para eso, puedes devolver una promesa desde el test, usar async/await o, en APIs más antiguas, emplear el callback done que Jest inyecta en la función de prueba.

Creación de pruebas unitarias con Jest en componentes de UI

Para ilustrar cómo se prueban componentes reales, imagina que tienes un botón y algunos componentes más complejos en React. Lo habitual es crear ficheros como Button.test.tsx o HomeComponent.spec.ts y usar Jest con la librería de testing adecuada.

Un primer caso típico es comprobar que el componente se renderiza con el texto correcto. Renderizas el botón con React Testing Library, buscas el texto “Click me” u otro similar y verificas que ese elemento está en el documento con un matcher como toBeInTheDocument.

Otro patrón que se repite mucho es el uso de jest.fn() para crear funciones simuladas (mocks) que actúan como manejadores de eventos o callbacks. De este modo puedes comprobar si se han llamado cuando el usuario hace clic, cambia un input o lanza una acción determinada.

En componentes más complejos, como formularios o modales, es muy frecuente preparar un objeto de handlers con varias funciones mockeadas mediante jest.fn(), pasarlo como props y luego usar expect(handlers.algo).toHaveBeenCalled() para asegurar que la lógica de eventos se dispara cuando toca.

Incluso puedes comprobar condiciones más elaboradas, como que según un estado determinado (por ejemplo, una propiedad currentState de un contenedor) aparezca un botón con un texto u otro. En estos casos montas el componente con distintos valores iniciales y verificas que el texto o el rol de los botones cambia como esperas.

Configuración básica de Jest en proyectos React con TypeScript

Para usar Jest en una aplicación React con TypeScript, el flujo de trabajo suele empezar por asegurar que tienes Node.js y npm (o yarn) instalados y un proyecto base de React (por ejemplo, creado con Create React App o Vite, adaptado a TS).

En un proyecto ya existente, lo habitual es instalar de desarrollo lo siguiente: jest, @testing-library/react, @testing-library/jest-dom y los tipos de Jest para TypeScript. Una vez instalados, puedes crear un archivo de configuración como jest.config.js o jest.config.cjs donde defines el entorno, el transformador de TypeScript y rutas relevantes.

En el package.json se suele añadir al menos estos scripts: «test»: «jest –watch» para ejecutar pruebas en modo observador mientras desarrollas, y «test:coverage»: «jest –coverage» para generar informes de cobertura y ver qué partes del código no estás tocando con tests, y para integrarlos en pipelines de CI/CD puedes seguir una guía para configurar un flujo CI/CD con GitHub Actions.

Jest, por defecto, puede configurarse para buscar ficheros cuyo nombre termine en .test.tsx o .spec.tsx (en el caso de React con TypeScript), lo que simplifica mucho la organización: colocas los tests junto a los componentes o en una carpeta específica de tests, y Jest se encarga de localizarlos.

Integrar Jest en proyectos Angular de forma manual

En Angular, históricamente las pruebas se han montado con Jasmine y Karma, algo que mucha gente considera lento y poco amigable para integraciones CI/CD. A partir de Angular 16 se han introducido opciones experimentales para usar Jest, pero si quieres algo estable, la ruta manual sigue siendo la más fiable.

En un proyecto Angular reciente (por ejemplo, creado con Angular CLI 17), el proceso típico para pasarse a Jest suele seguir estos pasos:

• Crear el proyecto con ng new project-test-jest y la configuración que necesites.
• Desinstalar Karma y Jasmine con npm, quitando paquetes como karma, jasmine-core y demás dependencias relacionadas.
• Eliminar del angular.json la sección de configuración de tests basada en Karma, ya que no la vas a usar.
• Instalar Jest y jest-preset-angular con npm install jest jest-preset-angular @types/jest --save-dev.
• Actualizar los scripts del package.json para que «test» ejecute Jest en vez de ng test, y añadir un script «coverage» que lance jest --coverage.
• Modificar tsconfig.spec.json para que los tipos pasen de Jasmine a Jest, indicando "types":

Después necesitas crear un archivo jest.config.js en la raíz del proyecto, normalmente apoyándote en jest-preset-angular. Ahí defines cosas como la raíz de los tests, la ruta del fichero de setup, los alias de módulos (moduleNameMapper) y qué archivos cuentan para la cobertura.

Finalmente, añades un src/setup-jest.ts que importe ‘jest-preset-angular/setup-jest’, lo que prepara el entorno de Angular para ejecutarse correctamente en Jest, incluyendo JSDOM y otras particularidades.

Ejemplos de pruebas en Angular con Jest: componentes y servicios

En Angular, los tests de componentes normalmente se apoyan en TestBed para montar el componente dentro de un módulo de testing, inyectar servicios y manejar el ciclo de detección de cambios.

Por ejemplo, imagina un HomeComponent que tiene propiedades como title, count, isVisible y data, y que en su ngOnInit solicita datos a un SampleService. El beforeEach típico configuraría TestBed con el módulo o los imports necesarios, registraría el servicio y crearía el fixture del componente.

Una primera prueba bastante básica sería simplemente expect(component).toBeTruthy(), para asegurar que el componente se crea sin errores. Aunque pueda parecer trivial, ayuda a detectar problemas de configuración o dependencias rotas.

Luego puedes testear la interacción del usuario con botones que incrementan un contador o alternan un booleano de visibilidad. Con fixture.debugElement.query(By.css(‘.clase’)) encuentras los botones, disparas eventos con triggerEventHandler('click', null) y compruebas que las propiedades del componente cambian como esperas tras llamar a fixture.detectChanges().

Para servicios Angular que llaman a APIs reales, la pareja HttpClientTestingModule y HttpTestingController es esencial. Se configura en un beforeEach, se inyecta el servicio y el controlador, y tras cada prueba se llama a httpMock.verify() para asegurarse de que no quedan peticiones pendientes.

Un test típico de servicio HTTP podría suscribirse a service.getPokemon(‘pikachu’), comprobar que HttpTestingController recibe una petición GET a la URL correcta y responder con req.flush(mockPokemon). En las aserciones se comprueba que los datos devueltos al suscriptor corresponden con el mock.

Snapshot testing y transformadores personalizados

Jest también permite hacer snapshot testing, muy habitual en componentes React. La idea es sencilla: renderizas un componente (por ejemplo con react-test-renderer), guardas su salida en un archivo snapshot y, en futuras ejecuciones, comparas lo que se renderiza con ese archivo.

Cuando el componente cambia de forma intencionada, puedes actualizar el snapshot con un comando como jest -u. Si la diferencia no era esperada, la prueba fallará y te obligará a revisar qué ha cambiado exactamente en la salida renderizada.

Con React 16+ y librerías como Enzyme puede haber advertencias en consola al mockear ciertos componentes, por cómo React valida los tipos de elementos. Algunos atajos son renderizar como texto plano, usar custom elements (etiquetas con guion y minúsculas), apoyarse en react-test-renderer o, en casos extremos, desactivar ciertas advertencias en la configuración de Jest.

Si tu proyecto necesita una transformación de código más avanzada, también puedes definir transformadores personalizados en Jest. En lugar de usar solo babel-jest, se puede recurrir a @babel/core y babel-preset-jest, configurando la clave «transform» de Jest para procesar archivos con tus propias reglas.

Buenas prácticas al escribir tests unitarios con Jest

Para que tus pruebas sean realmente útiles y no un lastre, conviene seguir unas cuantas pautas sencillas que, con el tiempo, se vuelven casi instintivas:

• Mantén cada test enfocado en una sola cosa: un comportamiento concreto, un escenario claro. Así son más fáciles de entender y de mantener.
• Usa descripciones de test expresivas: que cuenten qué hace la funcionalidad, no que repitan el nombre del método. Cuando un test falla, el mensaje debe tener sentido para ti y para tu equipo.
• Haz los tests independientes entre sí: no deberían depender del orden de ejecución ni del estado que dejan los demás. Cada prueba debe poder ejecutarse aislada.
• Saca partido a beforeEach y afterEach para reutilizar configuraciones comunes y limpiar recursos o mocks tras cada prueba.
• Apóyate en mocks y spies para aislar dependencias externas (APIs, servicios globales) y centrarte en la lógica que realmente quieres validar.
• No olvides los casos límite y los errores: no pruebes solo el camino de éxito; incluye inputs raros, tipos incorrectos, errores del servidor y estados vacíos.

Una vez que lanzas Jest con cobertura (por ejemplo, usando npm run coverage), obtendrás un directorio coverage con un informe HTML muy visual donde ver qué archivos y líneas se han ejecutado en los tests. Abriendo coverage/lcov-report/index.html puedes navegar fichero a fichero, lo cual es ideal para detectar zonas oscuras de tu aplicación que conviene cubrir.

Al final, todo este ecosistema de Jest, React Testing Library, jest-preset-angular, linters y herramientas de cobertura tiene un objetivo bastante claro: que puedas cambiar tu frontend con confianza, sin vivir con el miedo constante a romper la experiencia del usuario. Si tus pruebas están bien enfocadas, reflejan cómo se usa de verdad la aplicación y no se atan a detalles internos, se convierten en un seguro de vida para tus proyectos y en una base sólida sobre la que evolucionar tu código con calma, incluso en equipos grandes y con despliegues frecuentes.