← Back to list

Configuración inicial de proyecto de Next.js con TypeScript, SASS, Linting y Tests — parte 2

En el artículo anterior de como configurar nuestro primer proyecto NextJS estuvimos viendo una serie de herramientas que vienen ya…

Raúl Noa Pedroso · 2023-03-28 14:46 · 0 claps · 7.0 min read
#jest #test-coverage #nextjs #unit-testing #testing-library
Open on Medium ↗
Wiki topics: RAG · RAG & Retrieval 🌐 · Web Development 📚 · Books & Reading

Configuración inicial de proyecto de Next.js con TypeScript, SASS, Linting y Tests — parte 2

En el artículo anterior de como configurar nuestro primer proyecto NextJS estuvimos viendo una serie de herramientas que vienen ya preconfiguradas y que con solo pequeños ajustes podemos empezar a ocupar para desarrollar nuestra aplicación de React.

Una vez que comenzamos a desarrollar nuestro proyecto una parte importante para asegurar la calidad y que el desarrollo de nuevos requerimientos no afecte requerimientos existentes es probar nuestro código. Al momento de escribir este artículo esa configuración no viene por defecto y es responsabilidad nuestra escoger que tipo de framework utilizar para las pruebas, así como de configurarlo.

A continuación, veremos como configurar Jest para pruebas unitarias y revisar la cobertura de nuestro código.

Test suite con Jest

Test suite con Jest

Pruebas unitarias con Jest

Primero que todo necesitamos instalar Jest como dependencia. Desde la versión 12, Nextjs viene con una configuración para soportar Jest. Así que como estamos ocupando la versión 13 solo tenemos que instalar las siguientes dependencias que además habilitarán la muy utilizada librería “**@testing-library/react**” y realizar algunas configuraciones.

npm install --save-dev jest jest-environment-jsdom @testing-library/react @testing-library/jest-dom

Esto nos instalará:

Jest dependencias

Jest dependencias

Ahora también vamos a necesitar tener en nuestro proyecto las siguientes configuraciones. Primero necesitamos crear un archivo “jest.config.js” y “jest.setup.js” en la carpeta principal de nuestro proyecto con el siguiente contenido:

// jest.config.js
const nextJest = require('next/jest')

const createJestConfig = nextJest({
  // Provide the path to your Next.js app to load next.config.js and .env files in your test environment
  dir: './',
})

// Add any custom config to be passed to Jest
/** @type {import('jest').Config} */
const customJestConfig = {
  // Add more setup options before each test is run
  setupFilesAfterEnv: ['<rootDir>/jest.setup.js'],
  testEnvironment: 'jest-environment-jsdom',
}

// createJestConfig is exported this way to ensure that next/jest can load the Next.js config which is async
module.exports = createJestConfig(customJestConfig)
// jest.setup.js
// Optional: configure or set up a testing framework before each test.
// If you delete this file, remove `setupFilesAfterEnv` from `jest.config.js`

// Used for __tests__/testing-library.js
// Learn more: https://github.com/testing-library/jest-dom
import '@testing-library/jest-dom/extend-expect';
import '@testing-library/jest-dom';

Y por último incorporar a nuestro archivo “package.json” en la sección “scripts” el script:

"test": "jest"

Ahora solo necesitamos correr “npm run test” y nos dirá que Jest está configurado, pero actualmente no tenemos ningún test unitario creado en nuestro proyecto.

Corriendo Jest en proyecto sin pruebas unitarias

Corriendo Jest en proyecto sin pruebas unitarias

Para resolver esto creemos nuestros primeros tests creando una carpeta “tests” en la carpeta raíz y dentro de esta un archivo “index.test.tsx”. Aquí vamos a testear la página “Home” que se crea por defecto en nuestro proyecto.

Carpeta para pruebas unitarias

Carpeta para pruebas unitarias

import { render, screen } from '@testing-library/react';
import Home from '@/pages/index';

describe('Home', () => {
  it('renders a heading', () => {
    render(<Home />);

    const heading = screen.getByText(/Get started by editing/i);

    expect(heading).toBeInTheDocument();
  })
})

En caso de que la prueba falle y no encuentre el texto “Get started by editing” reemplázalo con el texto que tenga tu página Home y que quieras validar

En esta simple prueba validamos que el texto “Get started by editing” exista en la página Home y utilizamos RegEx para encontrar el texto independiente de si está en mayúscula o no.

Si ahora volvemos a correr el mismo script anterior nos debe mostrar como resultado:

Prueba con Jest pasó de forma exitosa

Prueba con Jest pasó de forma exitosa

Snapshots

Ahora habilitemos los snapshot. Los snapshot con Jest nos permiten tener un respaldo de cómo se visualizó el contenido de nuestro componente o página que estemos renderizando la última vez que corrieron las pruebas y se generó. Para así evitar que cambios que puedan afectar la experiencia actual.

Para eso incorporamos en nuestra suite de prueba el caso de prueba:

it('renders Home unchanged', () => {
        const { container } = render(<Home />);
        expect(container).toMatchSnapshot();
    });

Aquí estamos validando que el DOM del contenedor de nuestra página “Home” sea igual a la última copia que tenemos respaldad en nuestro snapshots. Si volvemos a correr las pruebas se creará una carpeta automáticamente “snapshots” con el nombre de nuestro archivo de pruebas y terminando en “.snap”.

Creación de snapshots

Creación de snapshots

Y dentro de este archivo estará la copia del dom renderizado cuando corrió por última vez de forma exitosa nuestra prueba.

Contenido de un snapshot con jest

Contenido de un snapshot con jest

Pruebas de Jest con snapshot

Pruebas de Jest con snapshot

Ahora si modificamos cualquier texto o contenido de nuestro “Home” y corremos las pruebas o solamente el caso del snapshot va a fallar debido a que el contenido cambió.

Snapshot falló

Snapshot falló

Esto es muy útil ya que nos permite verificar si se realizó un cambio en los textos o en el componente por accidente y corregirlo. En caso de que en realidad SI aplique realizar ese cambio en el contenido debemos actualizar nuestro snapshot antes de correr las pruebas para que no falle. Para eso es bueno incorporar el script:

"test:updateSnapshot": "jest --updateSnapshot",

Si corremos el script vamos a ver que nuestro archivo snapshot se actualiza con el cambio que hallamos realizado.

Actualización de snapshot

Actualización de snapshot

Y si corremos nuestras pruebas ahora si pasan sin problema.

Puedes ver las configuraciones realizadas hasta ahora aquí:

[embed]Feature enabling jest with snapshots by rnoap · Pull Request #2 ·… Description Enabled Jest for unit testing and snapshots. Motivation and Context Enabled support for create unit tests…github.com

Cobertura de código

Ahora lo siguiente es saber cuánto de nuestro código ha sido validado y que funciones faltan por cubrir.

Otra funcionalidad que podemos habilitar con Jest es el “coverage”, que nos retornará como resultado además de las pruebas que pasaron que porcentaje de todo nuestro código se está validando con nuestras pruebas.

El coverage podemos verlo simplemente ejecutando el siguiente script:

"test:cov": "jest --coverage"

Esto además de ejecutar nuestras pruebas nos permitirá ver cuánto de nuestro código está cubierto y que archivos estamos probando.

Jest pruebas con coverage

Jest pruebas con coverage

Además, automáticamente se creará en la carpeta raíz una nueva carpeta “coverage” donde si abrimos el archivo “index.html” podemos ver el detalle de lo que estamos probando.

Carpeta con el reporte del coverage generado por Jest

Carpeta con el reporte del coverage generado por Jest

También podemos cambiar el nombre de la carpeta donde se guarda el reporte de este coverage incorporando a “jest.config.js”:

const customJestConfig = {
    ...,
    coverageDirectory: "test-coverage",  
}

Detalle del coverage

Detalle del coverage

Mejorando la vista de coverage

Ahora, esto puede ser suficiente para ver el coverage, pero también podemos ver esta vista para de forma unificada tener mejor visión del nivel de pruebas que tenemos en nuestro proyecto.

Para eso tenemos que incorporar en el archivo “jest.config.js” la configuración de coverage que vamos a ocupar. Esto depende de la estrategia de coverage y la librería que vayamos a ocupar. En este caso vamos a ocupar la dependencia “jest-html-reporters”.

jest-html-reporters

jest-html-reporters

npm install jest-html-reporters --save-dev

Incorporamos la definición de “reporters” que nos permite definir cual se va a utilizar para generar el reporte del coverage que tenemos en el proyecto.

const customJestConfig = {
    ...,
    reporters: [
      [
        "jest-html-reporters",
        {
          "publicPath": "./html-report",
          "filename": "report.html",
          "openReport": false,
          "urlForTestFiles": "../",
        }
      ]
    ],  
}

Aquí definimos varias propiedades:

  1. publicPath”: Nombre de la carpeta donde se va a generar el reporte de la librería que tiene que ser diferente a “coverage” o al valor que hayamos definido en la propiedad “coverageDirectory”.
  2. filename”: Nombre del archivo que contendrá el resultado del coverage.
  3. openReport”: Si lo cambiamos a “true” abrirá de forma automática el reporte cada vez que se genera.

Si volvemos a correr el script “test:cov” ahora veremos que se genera una nueva carpeta en nuestro caso el nombre definido es “html-report”.

jest-html-reporters carpeta

jest-html-reporters carpeta

Al abrir el archivo “report.html” vemos la nueva vista de reporte con la configuración básica que ofrece.

jest-html-reporters detalle del reporte

jest-html-reporters detalle del reporte

Umbral de cobertura

Según vaya creciendo nuestro proyecto y en complejidad de funciones, un elemento importante es ir definiendo un “umbral de cobertura / coverage Threshold” como acuerdo de equipo.

Esto permitirá que una vez que alcancemos cierto nivel de coverage en nuestro proyecto, este no baje según se vayan sumando nuevas funcionalidades y pruebas.

Para esto definimos en “jest.config.js” la configuración:

const customJestConfig = {
    ...,
    coverageThreshold: {
        "global": {
            "branches": 80,
            "functions": 80,
            "lines": 80,
            "statements": 80
        }
    },
}

En este caso estamos definiendo que se debe alcanzar un 80% de cobertura para todos los puntos.

Por último, incorporemos a nuestro archivo “.gitignore” las 2 carpetas donde se guardan el reporte.

//.gitignore

#testing
test-coverage
html-report

Para ver estos cambios realizados para habilitar el coverage puedes revisarlo aquí:

[embed]Added | jest coverage configuration by rnoap · Pull Request #3 ·… Description Enable jest tests coverage Motivation and Context Improve Jest Coverage How Has This Been Tested? Unit…github.com

Conclusiones

Con esto terminamos las configuraciones básicas y mejores prácticas que necesitamos para empezar a trabajar en un proyecto con Nextjs implementado pruebas, linting, sass y Typescript.

Bibliografía

  1. https://nextjs.org/docs/testing#setting-up-jest-with-the-rust-compiler
  2. https://github.com/vercel/next.js/tree/canary/examples/with-jest
  3. https://www.npmjs.com/package/jest-html-reporters
  4. https://github.com/rnoap/nextjs-typescript-tests-linting

메타데이터
post_id
adce0ca8d03c
slug
configuración-inicial-de-proyecto-de-next-js-con-typescript-sass-linting-y-tests-parte-2-adce0ca8d03c
url
https://medium.com/@rnoa/configuraci%C3%B3n-inicial-de-proyecto-de-next-js-con-typescript-sass-linting-y-tests-parte-2-adce0ca8d03c
canonical_url
https://medium.com/@rnoa/configuraci%C3%B3n-inicial-de-proyecto-de-next-js-con-typescript-sass-linting-y-tests-parte-2-adce0ca8d03c
author_url
https://medium.com/@rnoa
status
ok
fetched_at
2026-07-25 23:29:14