Next.js 14: No hemos aprendido NADA 😡
Tags: testing, nextjs, webdev, programming
Published: 2023-10-30 07:55:47

Hace ya algún tiempo que Next.js está en el foco del desarrollo frontend. Es el framework de moda: rápido, moderno, fantasticoso (fantástico y maravilloso).

Como ocurre con cada nueva tecnología, miles de desarrolladores aspiran a ser *early adopters* y dedican una fortuna para reemplazar tecnologías obsoletas con las más relucientes. Next.js no es una excepción.

Quiero aclarar que ni soy un experto en Next.js ni soy un detractor. De hecho, **me gusta Next y creo que ofrece ideas y avances muy valiosos para la comunidad**. Sin embargo, he observado que están cometiendo un error, en mi opinión, GRAVE. Esta semana, tras la conferencia donde se presentó [next/learn](https://nextjs.org/learn), decidí que escribiría un artículo al respecto.

El error es tan fundamental que se puede resumir en una frase:

> El ecosistema de Next.js relega el testing.

A pesar de enfatizar constantemente las ventajas de rendimiento, la rapidez del compilador, la eficiencia del *app router* y la revolucionaria naturaleza de los *server-side-components*, en toda la documentación ni se menciona el TESTING.

![La documentación de next sin referencias a testing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/y9af60er021sn4m4agbo.png)

En versiones anteriores al *app router (pages)*, al menos contaban con [una sección sobre testing](https://nextjs.org/docs/pages/building-your-application/optimizing/testing) en el apartado de "optimizaciones". Sin embargo, esta sección ha desaparecido en la documentación actual.

Es sorprendente, pero parece que en pleno 2023 debemos recordar nuevamente la importancia del testing automático. Afortunadamente, en Vercel ya lo saben, pues el primer punto destacado de Next14 es que cuentan con 5000 tests en su base de código.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/jrt628f39za4d88tsdzd.png)

Aún así, por razones desconocidas, continúan omitiendo casi por completo toda referencia a testing. Cómo si sus clientes no necesitasen hacer pruebas.

Yo tengo una opinión bastante radical, creo que los tutoriales y ejemplos deberían seguir la metodología TDD y cada muestra de código debería incluir un test asociado. Aunque se que esto es una utopía que únicamente existe en mi cabeza, creo que al menos sería positivo que desde Next se promoviesen un MÍNIMO estas buenas prácticas y al menos preparasen el terreno para que la comunidad interesada en testing pueda investigar y generar contenido.

Al iniciar una app desde cero, no te pregunta por el framework de *unit testing* que utilizarás ni incluye un script de _test_ predeterminado.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m5ohzdmlbv0s3zylieg6.png)

Ni siquiera incluye un script de "test":


```json
{
"scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },
}
```

No me doy por vencido. Intentaré configurar Jest siguiendo [los ejemplos proporcionados en la documentación anterior](https://github.com/vercel/next.js/tree/canary/examples/with-jest).


El tutorial es bastante directo. Instalo las dependencias:

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

Luego, creo el archivo `jest.config.mjs`:

```tsx
import nextJest from 'next/jest.js'
 
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 config = {
  // 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
export default createJestConfig(config)
```

Y finalmente realizo un test de prueba. Todo parece funcionar.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xtbsbmabtw6d961ar04y.png)

Sin embargo, ¿qué ocurre con los *server-side components* asíncronos?

```tsx

async function getData(): Promise<string> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("World");
    }, 1000);
  });
}

export default async function Home() {
  const data = await getData();
  return <h1>Hello {data}</h1>;
}
```

Este componente funciona perfectamente en Next, pero al intentar ejecutar los tests nuevamente…

![Los tests fallando](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/blj5qma3a9imyt9ftvku.png)

Es evidente: no es posible realizar tests unitarios de páginas SSR. Actualmente, la única opción que conozco es utilizar tests E2E con Playwright o Cypress. 

Pero si queremos probar cosas tan _"sencillas"_ (o al menos comunes) cómo *layouts*, rutas complejas y otros aspectos que anteriormente eran fácilmente testables con Jest + Testing Library estamos totalmente abandonados.

## Conclusión

Hoy, resulta complejo (si no imposible) desarrollar una aplicación en Next.js con tests unitarios. Los tests son herramientas esenciales para garantizar la calidad del software y la eficiencia en el desarrollo.

Lamentablemente, el framework que promete liderar el desarrollo frontend en los próximos años parece desestimar la importancia del testing.

Me preocupa que, si ya es difícil convencer a los desarrolladores de realizar pruebas, si el framework no ayuda será una batalla perdida.

Espero que alguien del equipo de Next (preferentemente hispanohablante ;) ) lea esto y tome acciones, pues insisto: es una tecnología impresionante.